7dbf5e2ea7
When we're repainting, there's no point in polling for input events. We just read input events once before each repaint and send out events as needed. The input events come with an accurate timestamp, so this doesn't affect the timing information and client should always look at the event timestamps if they're trying to determine pointer motion speed or double click speed. If we go idle (stop repainting) we add the input devices back into the primary main loop and wait for the next event. This avoids waking up the compositor separately (one or more times per frame) to handle input events. We also avoid updating cursor position and other compositor state after the client has rendered its new frame, reducing lag between what the client renders and the pointer position. |
||
|---|---|---|
| clients | ||
| data | ||
| protocol | ||
| shared | ||
| src | ||
| tests | ||
| .gitignore | ||
| autogen.sh | ||
| configure.ac | ||
| Makefile.am | ||
| README | ||
| weston-desktop-shell.ini | ||
| weston-tablet-shell.ini | ||
Wayland Demos This repository contains a few demos application for the Wayland project. There's a sample compositor that can run on KMS, under X11 or under another Wayland compositor and there's a handful of simple clients that demonstrate various aspects of Wayland: