A grafikus felület várakoztatása nem a program, hanem az alatta lévő grafikus library feladata, ami itt a Xorg.
Xorgnál a következő felállások szoktak lenni (tudtommal):
- Meghívják az
XNextEvent() függvényt, ami ha nincs esemény, alvásba küldi a szálat a következő eseményig.
- Az XNextEvent()-et csak akkor hívják meg, ha van a queue-ben esemény, amit az XPending() függvénnyel ellenőriznek, ami viszont azonnal visszatér a queue-ben lévő események számával, ami ha nulla, akkor a program XNextEvent() helyett várakozik, de nem feltétlenül sleep segítségével.
Namármost, ez a micsoda a wxWidgets 3-at használja GUI-ra, ami tud más GUI widgetsetekre (GTK 1-2, Qt4, stb.) wrappelni, vagy natívan X11-el működni. Azt hiszem, wrapping esetében feltételezhetjük, hogy az említett widgetsetekben le van rendesen kezelve a dolog.
Ha a másik esetet nézzük, a wxWidgets X11-es library-jében megtalálod az evtloop.cpp fájlban a wxGUIEventLoop::Dispatch() függvényt. Amint látod, itt a kettes felállás van: XPending() == 0 esetén vagy ráhúz egy timeoutos select()-et az X11-es descriptorokra, vagy, ha Nano-X-szel volt forgatva a lib, akkor meghívja a GrGetNextEventTimeout() függvényt, ami pedig megint csak egy timeoutos select()-el várakozik. (https://raw.githubusercontent.com/ghaerr/microwindows/master/src/nanox/client.c)
Egyszóval nem maradt ki semmilyen sleep innen sem.
Namármost, a kurzor mozgatása maga is egy XEvent, tehát ha folyamatosan mozgatod a kurzort, akkor mind a select(), mind az XNextEvent() folyamatosan visszatéreget és ekkor a szál visszakapja a futást, azaz lehet rajzolni. Viszont, ha nincs mit rajzolni, akkor hiába kapja vissza, gyakorlatilag azonnal küldi is vissza pendingbe az egészet, márpedig te nem tudod akkora sebességgel mozgatni a kurzort, hogy két kurzormozgatás generálta XEvent között ne legyen legalább pár milliszekundum differencia, ergo nem tudsz "sleepless" állapotot felállítani.
Ha viszont túl sok mindent kéne rajzolni, akkor tovább tarthat a kirajzolás, mint amennyi idő a folyamatosan mozgatott kurzor okozta XEvent-ek között eltelt, ennek megfelelően az XEvent-ek fel fognak torlódni a queue-ben, ami viszont ténylegesen perzisztens azonnali visszatérést fog eredményezni az eseményfigyelő függvényeknél, ergo így felállhat a "sleepless" állapot.
Ez így persze nem biztos, csak feltételezés, logika és némi tapasztalat alapján, de szerintem nem az időzítéssel van baj, hanem annyi mindent akar rajzolni kurzormozgatáskor (valószínűleg feleslegesen), hogy bedugítja az event queue-t.