Artifacts when resizing window on GL backend

[LeonMatthesKDAB]

trafficstars

The window still flickers with the original size of the window, after resizing via changing e.g. the width.

Also, something about the window scale seems off (I'm using 2x display scaling). It seems the new window uses 1x window scale, whilst the initial used 2x scale.

Minimal example:

MyApp := Window {
  width: 480px /*make this 240px*/; height: 480px;
  background: #ffcaff /* then change to: #ff00ff */;
}

screenshot:

In this case, you can clearly see, that the new window contents even ended up outside the window border. This only happens with the GL backend, the Qt backend works fine. I launched the preview with both slint-viewer, as well as from slint-lsp (using neovim). The issue appears in both cases.

My setup:

• Fedora 36
• GNOME desktop (2x display scale)
• XWayland
• slint version 0.3
• slint-viewer & slint-lsp installed via cargo install.

[tronical]

I can reproduce this (somewhat) when using weston --scale=2 and following the above steps.

Since this is a setup with client side window decorations, etc. - this is most likely a bug in either slint, winit or glutin.

[LeonMatthesKDAB]

Ah, also, as I forgot to mention it in the initial report: My CPU/GPU: AMD Ryzen™ 7 PRO 5850U with Radeon™ Graphics × 16 Linux kernel: 5.18.19-200.fc36.x86_64

[tronical]

So we end up calling set_inner_size on the winit::Window but we don't receive a resize event in return, that we would use to resize the OpenGL surface. In consequence, winit draws its client side window decorations at the right place, but since we never shrink the GL surface, we draw in that one and that's out of bounds.

I can reproduce this also with a scale factor of 1.

[LeonMatthesKDAB]

Hm, that might be a bug in winit then :thinking: Or maybe even OpenGL driver related. A workaround could be to just resize the OpenGL surface every time, no matter whether you receive a Resize event :thinking:

[tronical]

Yes, this is what we did up until commit f4ddfa5ef69aea5b16822d41a27d50d7bd002725 . But that itself is not enough to fix it AFAICS :(

So concretely

diff --git a/internal/backends/winit/renderer/femtovg.rs b/internal/backends/winit/renderer/femtovg.rs
index 0b69d3612..641436cb6 100644
--- a/internal/backends/winit/renderer/femtovg.rs
+++ b/internal/backends/winit/renderer/femtovg.rs
@@ -134,6 +134,7 @@ fn render(&self, canvas: &FemtoVGCanvas, window_adapter: &dyn WindowAdapter) {
         let height = size.height;

         canvas.opengl_context.make_current();
+        canvas.opengl_context.ensure_resized();

         let window = WindowInner::from_pub(window_adapter.window());

ensures the right size of the GL surface for me. But despite calling swap_buffers(), that frame isn't show by Weston for me until I hover the window with my mouse.

[tronical]

I've reduced this down to a glutin test case and filed https://github.com/rust-windowing/winit/issues/2499

[ogoffart]

Is this issue fixed now?

[tronical]

This problem is now reproducible by just running the gallery example under Weston with FemtoVG or Skia OpenGL. (using v1.1.0)

[tronical]

Once we can use https://github.com/rust-windowing/winit/pull/2930 then we might be able to fix this in a somewhat elegant way.