(13-09-2021, 01:11 AM)seninha Wrote: But it is too slow to redraw the window at every mouse motion...

There is another solution: only redraw every once in a while. Mouse motion events occur at a really high frequency, so attempting to support that frequency is doomed to feeling sluggish and painful. I discovered that when trying to do it with wmutils (which is even worse than in your case, because linking an event to a resize request occured in a shell script).

I don't know Xlib well, so take my advice with a grain of salt (especially since Xlib is synchronous, while xcb is not), but X event (including mouse move) have a field named "time", which you can use to your advantage: if you save the time of each mouse event, you can compare the time of the current event to the last one, and ignore events that are too "close" from each others, thus forcing the window painting at a maximum framerate.
Here is some pseudo-code (using XCB, sorry):


The value of "32" between two events was chosen semi-arbitrarily. 32 milliseconds means that you will (at most) repaint your window at ~31 frames per seconds. This is the frame rate used in cinematography, and due to retinal persistence ~24 frames per second will be perceived as "smooth" for most people. You can lower that number to get a higher framerate, but that's at the expense of hitting heavier load on your CPU. After some testing, I found 30 to be a pretty decent value (rounded at 32 because I like powers of 2 !), and you're allowed to steal it. See https://git.z3bra.org/glazier/file/glazier.c.html#l461 for a "real life" example (my own WM). Note that in my case, I also only redraw the window outline, but it's mostly because I find it more pleasant to the eye. I tried to redraw the whole window at that rate, and it worked well (it's just more ugly to see the window content shrink/grow multiple time as your resize the window IMO).

Edit: I modified my code to teleport/repaint borders instead of drawing the outline. No lags can be seen: https://0x0.st/-xVS.webm