schcom: repaint what changed, and stop rendering frames nobody sees
Moving the mouse repainted the whole screen. At 1280x800 that is a million pixels of desktop fill, every surface re-blitted, and a 4 MB copy to the framebuffer -- per event. Under emulation the pointer lagged the mouse by whole seconds, and that was not the emulation's fault: moving a 10x10 cursor does not require touching four megabytes. Two changes, and the second matters as much as the first. Damage tracking: one rectangle, unioned from whatever actually changed, and only those rows are redrawn and copied out. A pointer move damages where it was and where it is; a commit damages that surface; a client going away damages what it had. One rectangle rather than a list, because in practice the changes are a cursor and the window under it, and a list costs more bookkeeping than it saves. Draining input: a single mouse movement produces a burst of EV_REL ending in EV_SYN, and the loop handled one event per poll and repainted. So the compositor rendered every intermediate position of a cursor that was never seen at those positions. Both queues are now drained before anything is painted. handle_input grew a distinct "queue empty" return for it -- EV_SYN changes nothing but is not the end of the burst, and a drain that stopped there would leave the rest queued. Also cuts the loader's resolution prompt from four seconds to one and a half, on both the BIOS and UEFI paths. Four was mine and it was too long: it is paid on every unattended boot, and adding four seconds to every start to offer a menu nobody usually wants makes the common case worse to serve the rare one. schcom-test passes, including two overlapping clients and stacking order. bootcheck 108 [ok]. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
eafdddefbc
commit
bf9ac843f7
4 changed files with 130 additions and 37 deletions
Binary file not shown.
Loading…
Reference in a new issue