<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - With Vsync disabled, Weston almost halves *visible* frame update rate, compared to X desktop" href="https://bugs.freedesktop.org/show_bug.cgi?id=106736#c17">Comment # 17</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - With Vsync disabled, Weston almost halves *visible* frame update rate, compared to X desktop" href="https://bugs.freedesktop.org/show_bug.cgi?id=106736">bug 106736</a> from <a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(In reply to Eero Tamminen from <a href="show_bug.cgi?id=106736#c16">comment #16</a>) > (In reply to Pekka Paalanen from <a href="show_bug.cgi?id=106736#c15">comment #15</a>) > > Oh right, like Michel Dänzer said in IRC, the repaint-window should probably > > be dynamically adjusted based on performance. That would be a nice research > > project. Do you think that could be the solution, Eero? > > It definitely seems something worth trying. Now if someone had the will and the time... > While games are not really my thing [1], I would image gamers to want 144Hz > monitor with "FreeSync" and configure the game so that he gets somewhere > between e.g. 72-144Hz update frequency with variable Vsync rate. > > However, something like that should be done with fullscreen / compositor > bypass. Yes, very much. In the past, Mario Kleiner actually posted some tentative patches IIRC for allowing fullscreen composite-bypass path to reduce the display latency even further by essentially removing the compositor deadline for new content and flipping client buffers very close the vblank or something like that. But if the compositor does flips very close to vblank to reduce display latency, then that buffer has better finished drawing already, or it will definitely miss the vblank. Another problem with DRM KMS is that once you program a flip, you cannot cancel it and you cannot program another until it has finished. This means that programming a flip ASAP when a client provides new content means the future content for display is locked down early, which means there is no chance for the client to submit another frame closer to the same vblank. So while a Wayland compositor has a wl_buffer mail-box towards the client which the client can update at any time, the compositor needs to sample that mailbox some time before the vblank and it can do that at most once per display refresh. When to sample is defined by repaint-window. > [1] I'm more into emulators (one of the maintainers for one), those also > need Vsync differing from 60Hz (in my case 50 or 71). Because those > frequencies are fixed during emulator run, changing whole display refresh > rate would be one option there, but "FreeSync" would be nice there too. Right. We have had some tentative Wayland protocol bits to allow a client to suggest a refresh rate, which the compositor might honour by reprogramming the display video mode without VRR. VRR would be very interesting to support, even if only for fullscreen composite-bypass.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>