https://bugs.freedesktop.org/show_bug.cgi?id=106736
--- Comment #6 from Pekka Paalanen <ppaala...@gmail.com> ---
For an explanation, see:
http://ppaalanen.blogspot.com/2015/02/weston-repaint-scheduling.html
The GPU is traditionally a single task at a time, non-preemptive, sequential
processor. The application and the compositor compete of the GPU.
If an application is not throttled to the frame callback, it's possible it will
start a new frame before it has given the compositor a chance to get the
current frame on screen. When this happens, the compositor has to wait for the
app's new frame to finish before the compositing task can run, and only after
that the compositor can actually show the frame on screen.
Because Weston (all Wayland compositors, ideally) only repaints at most once
for each refresh and always syncs to vblank, it predicts what is the next
vblank it could hit, and makes a delay so that it will have repaint-window
milliseconds of time to submit and finish the composite GPU job. If other GPU
jobs make the compositor miss the vblank, it'll postpone the presentation by a
whole refresh period before weston even considers repainting again.
So the first thing is to make the application "sync to vblank", IOW, make it
repaint only as a response to the frame callback events and see what effect
that makes.
repaint-window should be the lowest possible value where the compositor still
makes the vblank deadline, to reduce application-to-screen latency.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
