[Wayland-bugs] [Bug 106736] With Vsync disabled, Weston almost halves *visible* frame update rate, compared to X desktop

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106736

Eero Tamminen <eero.t.tamminen at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Weston almost halves        |With Vsync disabled, Weston
                   |*visible* frame update rate |almost halves *visible*
                   |from what application       |frame update rate, compared
                   |actually produces           |to X desktop
           Priority|medium                      |low
           Severity|normal                      |minor

--- Comment #9 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to Pekka Paalanen from comment #6)
> 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.

With Vsync things are fine. This bug is about behavior when Vsync is disabled,
and Weston being clearly worse at that, than X compositor(s) like Compiz.

-> I updated the title to be more specific about this.


Where this would matters:

* All (3D) benchmarks run with Vsync disabled, and often games are run with
Vsync disabled too.

* Those are often run in fullscreen where it wouldn't matter if compositing
were disabled, but Weston has regressed in that with modifier support, see bug:
106732

As there's a workaround, and bug 106732 will fix the main issue with this, I
changed this to low/minor.


> repaint-window should be the lowest possible value where the compositor
> still makes the vblank deadline, to reduce application-to-screen latency.

Ok, so prioritizing compositor frames wouldn't help, only repaint value does.

Do you happen to know, is Compiz (clearly) better at this because it uses
higher latency value?  Or does it adapt the value based on previous application
frame timings?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20180601/fdad2dec/attachment-0001.html>