Consistent graphical glitches on window corners throughout the installer

[local-optimum]

Regardless of dark or light mode, the corners of the installer windows glitch frequently throughout, sometimes on mouseover and sometimes when clicking actions, this produces a lot of flickering during the installer slideshow as well.

Screencast from 13-02-23 08:56:58.webm

Potentially unrelated but when transitioning from the slideshow to the 'installation complete' screen the slideshow is rescaled to about 2/3 the size of the main window oriented to the top left briefly as it fades out creating an ugly transition

[jpnurmi]

We use the Handy library to round the bottom corners of the installer window:

Handy window	Plain GTK window

I don't know what is it with the combination of libhandy and Flutter that is causing this but I'm afraid our best bet is to drop libhandy and use a plain GTK window instead. Rounded bottom corners may look nice and modern but there's very little value in having them if it screws up the other corners...

[local-optimum]

Agreed.

[jpnurmi]

The bug is reproducible on X11 without Flutter and even without libhandy. I was able to trim the Flutter embedder down to a plain GTK test case. People with AMD cards are unaffected. Turning on VSync helps with Intel at least. Nvidia is unclear.

• https://github.com/jpnurmi/oh-my-corners
• https://gitlab.gnome.org/GNOME/gtk/-/issues/5600
• https://warthogs.atlassian.net/browse/DT-1045 (internal)

[elioqoshi]

I had the same issues when I was testing last week. Doing another round for better documentation.

With the current states of things I'd also highly advise to drop libhandy if it causes these issues. For what's worth, dropping round corners (also every where on Desktop) is something I agree with but might need further inspections

[jpnurmi]

We found out that the problem is not in libhandy, after all. The problem is in GTK's OpenGL backend for X11.

I guess the options we have are:

• try to get https://gitlab.gnome.org/GNOME/gtk/-/issues/5600 fixed in GTK,
• set GDK_RENDERING=image on X11, or
• switch to Wayland.

[elioqoshi]

Not sure of the full implications of this, though fixing it in GTK seems like the most sustainable solution, but might be more time-consuming. set GDK_RENDERING=image on X11 would be a good fallback I think?

[jpnurmi]

It's not 100% clear to me what the consequences of setting GDK_RENDERING=image are. The documentation suggests that it "essentially turns off all hardware acceleration inside GTK".

GDK_RENDERING If set, selects the way how GDK creates similar surfaces. This affects both the functionality of the function gdk_window_create_similar_surface() as well as the way GDK creates backing surfaces for double buffering. The following values can be used: similar: Create similar surfaces to the window in use. This is the default behavior when the variable is not set. image: Always create image surfaces. This essentially turns off all hardware acceleration inside GTK.

On the other hand, the GTK devs suggest removing the old OpenGL backend for X11 and "letting it do the same thing as on Wayland". And then there's this comment that suggests GDK_RENDERING=image being even better:

I did this at the time, and yes, it's an improvement. But you can do better. If I instead set GDK_RENDERING=image, then I see an enormous improvement, from total choppiness to complete smoothness. As far as I can remember, that has the effect of suppressing even more X11-specific code than just gdk_x11_gl_context_texture_from_surface(). So yes, doing the same thing as Wayland seems to work pretty well.

[kenvandine]

I've confirmed GDK_RENDERING=image at least fixes the artifacts when installing in qemu

[jpnurmi]

I'm leaving this ticket open as a reminder to follow up on https://gitlab.gnome.org/GNOME/gtk/-/issues/5600

[elioqoshi]

@kenvandine Can we try to see if we can have additional QA testing on this one and ensure this is addressed? I want to make sure we can bury this properly for this release.