[Wayland] VSync loop does not pause when the browser is idle
Categories
(Core :: Widget: Gtk, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox89 | --- | affected |
People
(Reporter: val, Unassigned)
References
(Blocks 1 open bug)
Details
When nothing is changing in the browser with widget.wayland_vsync.enabled=false, there are no wayland events happening at all.
With widget.wayland_vsync.enabled=true, even when nothing is happening and the browser is unfocused, WAYLAND_DEBUG=1 still spams this over and over again:
[921493.920] wl_callback@58.done(11425277)
[921493.924] -> wl_surface@55.set_buffer_scale(2)
[921493.926] -> wl_surface@55.frame(new id wl_callback@58)
[921493.928] -> wl_surface@55.commit()
[921510.596] wl_display@1.delete_id(58)
It would be nice to not waste any CPU time on requesting and processing these frame callbacks when no new frames are being rendered and the browser is completely idle.
(Also no need to set_buffer_scale when not even sending a new buffer…)
|
||
Comment 1•3 years ago
|
||
Robert, you solved something similar in Mutter right?
|
|
||
Updated•3 years ago
|
|
||
Comment 2•3 years ago
|
||
A bit of context here: the FF vsync infrastructure is optimized for classical buffer swap events like we have on other platforms, including X11. So whenever FF may want to draw in the future, it enables the vsync source, assuming it just passively listens to those events. If nothing happens for a short while, it should disable the vsync source again until it needs it again.
I just checked again using WAYLAND_DEBUG=1 firefox and things work as expected on nightly+gnome - frame callbacks are requested more often than on some other Wayland apps, but still stop being requested when really being idle. Greg, can you confirm that? Because if you see continues frame request, then there's a bug somewhere.
So get optimal behaviour, we'd need to implement bug 1563075, which would change the architecture to be more Wayland friendly, but that's a big undertaking with relatively little gain AFAICS.
Concerning the scale part: that's something we should indeed fix - we only need to set it when something changed.
|
Reporter | |
Comment 4•3 years ago
|
||
Hm, it actually does stop most of the time now. I guess let's close in favor of bug 1563075.
Description
•