Except for mouse and keyboard clicks.
Otherwise I never understood why the graphics package wants to let me know my window is exposed. Is there something out of date in my bit map buffer? How the frig will a graphics co-processor know that?
Wayland does it better. The client knows how accurate is the bit map, let the client signals the graphics processor, the the updated bit map can be exposed when needed.
The mouse clicks make sense for messages. But there is no human punching the screen unless it is touch screen, and touching the screen does not coincide with redrawing it, quite the opposite. The Wayland architecture figured this out, and I guess no one questioned it since the message loop was needed for mouses anyway.
The whole windowing revolution was built around moving bitmaps automatically, which is why you do not need to redraw your bit map whenever it is exposed, you already drew it, so go ahead and expose it, don't tell me. Anyway, I am skipping the message loop. It works for Xchars v2 ,when you put a string, Xchars writes it to bitmap and flushes the message queue. When Xchars does mouse clicks, then Xchars activates the message loop.
The pros will tell me that window draw messages are needed to prevent flicker, when my bit map is not double buffered, the graphics processor needs treat it a bit like shared memory. The event really means just what is says, the window is being moved, and the client requested a warning. This text will not flicker, it will likely be drawn to bit buffer faster than the process timeout.
No comments:
Post a Comment