Should compress MotionNotify events

[luebking]

Makes hovering more reactive. Do you need a pull request or similar?

diff --git a/dmenu.c b/dmenu.c
index c4b2899..6c66db8 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -955,6 +955,8 @@ run(void) {
                        continue;
                switch(ev.type) {
                case MotionNotify:
+                       while(XCheckTypedEvent(dc->dpy, MotionNotify, &ev))
+                               (void)0;
                        pointermove(&ev);
                        break;
                case ButtonPress:

[sbstnc]

Thanks for the contribution! How does it make it more reactive though? Is it because of XCheckTypedEvent? Doesn't that just copy matching events?

[luebking]

When you move the pointer, you generate a bazillion motion events (ok, "more or less") - 1000 ev/s isn't uncommon. W/o compression, every event will trigger a pointermove() call, which does some calculations, repaints and XSyncs, ie. the events are handles as fast as your system can go (and the server communicates)

The result is that you can outperform the system. You moved the pointer 500 pixels, but dmenu has only processed 200 of them, what feels laggy (leaving the CPU overhead aside)

XCheckTypedEvent processes up the event queue and as long as the next event is a motion event as well, waiting to be handled anyway, assigns that to ev. You'll only process as many motion events as client & server can handle, not more. This can cause jumps (but dmenu is very lean, so you'll virtually never fall below 60 fps), but prevents a behavior that feels like dragging the selection through jelly. Try to add a longer usleep to pointermove() to stress the bad behavior which is covered by this (not so uncommon ;-) approach.