1509937 - [Wayland][OpenGL] GL subsurface is not glued perfectly to the GTK window, resize lag is visible

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Val Packett]

Attachment: firefox-wayland-resize-lag.png

When resizing a window on Wayland backend with GL accelerated compositing, the GL subsurface is not perfectly glued to the GTK parent surface, so when resizing it's easy to see a gap between the rendered Firefox content and the GTK border/shadow. It's even possible to let go of the resize at the right moment to keep the gap. (see screenshot)

Comment 1

[Val Packett]

Removed the async repaint on resize patch https://bugzilla.mozilla.org/attachment.cgi?id=8963005 patch (from bug 1438144) from my build: the border is still not perfectly glued, now there's some glitches visible when resizing.

Comment 2

[Val Packett]

(oops, that's been software rendering mode. GL doesn't work without that patch.)

Comment 3

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Can you please test when Bug 1511951 lands? I can't reproduce it with it.

Comment 4

[Val Packett]

I've been using that patch (and the previous suggested one too) already.

I'll see if bug 1489902 instead of async repaint fixes it.

Comment 5

[Val Packett]

With sync repaint, it's different, but still not perfect. The gap is hidden when expanding the window (to the right), but even more visible than before when shrinking (to the left).

Comment 6

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Which system do you run please?

Comment 7

[Val Packett]

(In reply to Martin Stránský [:stransky] from comment #6)
> Which system do you run please?

Radeon RX 480, HiDPI screen, FreeBSD 13-CURRENT / drm-4.16, Mesa 19.0.0-devel (a couple days old), Weston master, GTK 3.24.2, Firefox built on December 6 (right after bug 1511951 landed)

Comment 8

[Val Packett]

With WebRender (blank window fixed by attachment 9034351 [details] [diff] [review] from bug 1514156) it's worse than with GL compositing. The whole window content can partially go out of the visible surface vertically. Though one thing I noticed is that it's a bit better when the page is active, e.g. if it has a video playing.

I recorded a video: https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/firefox-wl-wr-resize.webm

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

(In reply to greg from comment #8)
> With WebRender (blank window fixed by attachment 9034351 [details] [diff] [review]
> [review] from bug 1514156) it's worse than with GL compositing. The whole
> window content can partially go out of the visible surface vertically.
> Though one thing I noticed is that it's a bit better when the page is
> active, e.g. if it has a video playing.
> 
> I recorded a video:
> https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/firefox-wl-wr-
> resize.webm

That's great - it would actually help to debug it.

Comment 10

[Val Packett]

Looks like this was a Mesa bug (solved by https://gitlab.freedesktop.org/mesa/mesa/merge_requests/252 "wayland/egl: Ensure EGL surface is resized on DRI update_buffers()") as suggested by ame in https://bugzilla.mozilla.org/show_bug.cgi?id=1508594#c12 — after updating mesa-git, seems like the synchronization is fine and the window never ends up in this weird offset state after letting go of resize!

What happens during resize is pretty choppy though, every frame is far from perfect™.

WebRender: https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/fx-newmesa-resize-wr.webm

Basic GL layers: https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/fx-newmesa-resize-gllayers.webm

But I guess this issue is solved.

Comment 11

[Kestrel]

Fixed on Ubuntu 19.04 by Mesa 19.0.2.