Window maximizing with Fl_Gl_Window

[Lukas Lang]

I am encountering an issue with maximizing/restoring Windows that contain a Fl_Gl_Window: It seems the Fl_Gl_Window is not properly redrawn when the Window changes to/from a maximized state. As a demonstration, I recorded the behavior of the OpenGL3test.cxx example on my Ubuntu 20.04 system:

(https://i.imgur.com/tFn9rMZ.gif)

As you can see, resizing the Window manually or toggling the "Double-Buffered" checkbox off and on again fixes the issue, probably because the window is forced to redraw again.

Is there a way I can fix this behavior, e.g. by setting some flag or forcing the window to redraw at an appropriate time?

[Matthias Melcher]

Hmm, in the System Driver that you are using, FLTK should generate a resize() wich in turn should set the damage flags and redraw the entire screen. Maybe the maximise event is happening before the window is actually maximised. X11 and Wayland guys?

When the user maximizes a window, it will receive a FL_FULLSCREEN event in `handle()`. If it is not handled by the window, it should be propagated to all children. Maybe you can use that event to call `redraw()` on the GL window. Maybe a delayed redraw() will do it. - This is of course just a quick-fix. It will be fixed inside the library I am sure. I don't used Ubuntu myself, and it works correctly on a current Mac.

[Albrecht Schlosser]

On 1/27/23 13:55 Lukas Lang wrote:
> I am encountering an issue with maximizing/restoring Windows that
> contain a Fl_Gl_Window: It seems the Fl_Gl_Window is not properly
> redrawn when the Window changes to/from a maximized state. As a
> demonstration, I recorded the behavior of the OpenGL3test.cxx example
> on my Ubuntu 20.04 system:

I just tried the demo on my Linux Mint 20 which is based on Ubuntu 20.04
and it works as expected for maximizing and restoring (and manually
resizing as well). I tried both X11 and Wayland backends, both work fine.


I have no idea why it doesn't work on your (Lukas') system. Maybe an
issue with the OpenGL driver? What graphics adapter do you have, and can
you maybe change the graphics driver or some optimization level?


Other questions:
 - which (exact) FLTK version are you using (download version, Git
revision,...)
 - which desktop are you using? Is it a Wayland enabled desktop, or is
it pure X11?
 - if the former (Wayland), can you run the demo with the X11 backend
(FLTK 1.4 current)?

The latter would be something like

$ FLTK_BACKEND=x11 ./OpenGL3test

(replace x11 with wayland to use the Wayland backend if this is enabled
in your FLTK 1.4 build).

[Ian MacArthur]

On Friday, 27 January 2023 at 23:00:20 UTC Albrecht Schlosser wrote:

On 1/27/23 13:55 Lukas Lang wrote:
> I am encountering an issue with maximizing/restoring Windows that
> contain a Fl_Gl_Window: It seems the Fl_Gl_Window is not properly
> redrawn when the Window changes to/from a maximized state. As a
> demonstration, I recorded the behavior of the OpenGL3test.cxx example
> on my Ubuntu 20.04 system:

I just tried the demo on my Linux Mint 20 which is based on Ubuntu 20.04
and it works as expected for maximizing and restoring (and manually
resizing as well). I tried both X11 and Wayland backends, both work fine.


I have no idea why it doesn't work on your (Lukas') system. Maybe an
issue with the OpenGL driver? What graphics adapter do you have, and can
you maybe change the graphics driver or some optimization level?

OK, so I tried a few boxes (and also tried WSL2, since I have my Win11 box running anyway; my WSL2 setup is basically Ubuntu 22.04, FWIW.)

The results were mixed: I have one laptop, with Ubuntu 22.04 with an Intel GPU, that behaves as the OP showed, when running in X11 mode. Running in Wayland mode it is fine, no problem.

Other systems were fine in either X11 or Wayland modes, including WSL2 (though it has its other problems, of course...)

I'd be interested to know what GPU the OP has, along with the questions Albrecht asked; it may be something to do with the Intel GLX drivers, since it does not *appear* to be a specific fltk issue here (or at least, fltk works OK on some systems, at any rate!)

[Ian MacArthur]

On Monday, 30 January 2023 at 10:18:40 UTC Ian MacArthur wrote:

The results were mixed: I have one laptop, with Ubuntu 22.04 with an Intel GPU, that behaves as the OP showed, when running in X11 mode. Running in Wayland mode it is fine, no problem.

And, FWIW, the test/cube demo _does not_ show this behaviour - I *assume* because it is being constantly redrawn and hence hiding the issue...

 

[imm]

On Mon, 30 Jan 2023 at 10:18, Ian MacArthur wrote:
>
> OK, so I tried a few boxes (and also tried WSL2, since I have my Win11 box running anyway; my WSL2 setup is basically Ubuntu 22.04, FWIW.)
>
> The results were mixed: I have one laptop, with Ubuntu 22.04 with an Intel GPU, that behaves as the OP showed, when running in X11 mode. Running in Wayland mode it is fine, no problem.

So... here's an additional observation: on the "failing" laptop, the
mis-behaviour "often" (most times but not always) appears if the view
is in double-buffered mode when I switch it to fullscreen. If the view
is in single-buffer mode, it "usually" works fine.
So it may be an issue with flipping the buffers in the Intel GLX or some such?

Don't really know...

FWIW, I tried a few things, and so long as the GL view is
single-buffered, it basically seems to work OK; if the GL view is
double-buffered, the front buffer does not get consistently updated -
not just resizing to fullscreen, but some other refreshes seem to get
missed too.
And: This may be an alternate explanation for why the test/cube demo
is unaffected, since it is single-buffered.

[Albrecht Schlosser]

On 1/30/23 11:56 imm wrote:

On Mon, 30 Jan 2023 at 10:18, Ian MacArthur wrote:

... I have one laptop, with Ubuntu 22.04 with an Intel GPU, that behaves as the OP showed, when running in X11 mode. Running in Wayland mode it is fine, no problem.

So... here's an additional observation: on the "failing" laptop, the
mis-behaviour "often" (most times but not always) appears if the view
is in double-buffered mode when I switch it to fullscreen. If the view
is in single-buffer mode, it "usually" works fine.
So it may be an issue with flipping the buffers in the Intel GLX or some such?

Don't really know...

FWIW, I tried a few things, and so long as the GL view is
single-buffered, it basically seems to work OK; if the GL view is
double-buffered, the front buffer does not get consistently updated -
not just resizing to fullscreen, but some other refreshes seem to get
missed too.
And: This may be an alternate explanation for why the test/cube demo
is unaffected, since it is single-buffered.

I also have Intel graphics and I can not see the switch to fullscreen failing. I tried all combinations with double buffered on and off:

- hybrid build, running Wayland backend
- hybrid build, running X11 backend (which uses Cairo graphics)
- pure X11 build (which uses X11 graphics)

Here are my system details, in case it helps (Linux Mint 20 is based on Ubuntu 20.04 LTS):

$ inxi -SG
System:    Host: xxx Kernel: 5.4.0-135-generic x86_64 bits: 64 Desktop: Gnome 3.36.9 Distro: Linux Mint 20 Ulyana 
Graphics:  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel 
           Display: wayland server: X.Org 1.20.13 driver: modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa Intel UHD Graphics 620 (WHL GT2) v: 4.6 Mesa 21.2.6

FWIW, if you like to compare or post your own details: 'inxi' can be installed on Ubuntu with `apt install inxi` and I believe it's in Debian as well.

Note that I'm currently running the Gnome/Wayland desktop ("Gnome 3.36.9"). Switching to "fullscreen" shows a kind of "animation", obviously updating the screen many times. Maybe this animation makes it work? Ian, how does your failing system(s) switch to fullscreen, is it all in one step, or is it animated?

BTW: I just checked that the OP's animated GIF shows the switch to fullscreen in one step (not animated), maybe the (mis)behavior depends on the desktop (WM)?

[imm]

On Mon, 30 Jan 2023 at 13:38, Albrecht Schlosser wrote:
>
> I also have Intel graphics and I can not see the switch to fullscreen failing. I tried all combinations with double buffered on and off:
>
> - hybrid build, running Wayland backend
> - hybrid build, running X11 backend (which uses Cairo graphics)
> - pure X11 build (which uses X11 graphics)

Yup - tried those combos on my "failing" laptop, and it is consistent
- Wayland just works; X11 (either "pure" or X11 backend) exhibits the
failure when the GL is double-buffered, but works OK if the GL is
single-buffered.

> Here are my system details, in case it helps (Linux Mint 20 is based on Ubuntu 20.04 LTS):
>
> $ inxi -SG
> System: Host: xxx Kernel: 5.4.0-135-generic x86_64 bits: 64 Desktop: Gnome 3.36.9 Distro: Linux Mint 20 Ulyana
> Graphics: Device-1: Intel UHD Graphics 620 driver: i915 v: kernel
> Display: wayland server: X.Org 1.20.13 driver: modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz
> OpenGL: renderer: Mesa Intel UHD Graphics 620 (WHL GT2) v: 4.6 Mesa 21.2.6
>
>

Here's what I get... does not look all that different (except maybe
you have a newer GPU than me, this laptop is old...)

$ inxi -SG
System:
Host: xps-laptop Kernel: 5.15.0-58-generic x86_64 bits: 64
Desktop: GNOME 42.5 Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
Graphics:
Device-1: Intel HD Graphics 620 driver: i915 v: kernel
Device-2: Microdia Integrated Webcam HD type: USB driver: uvcvideo
Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.1
compositor: gnome-shell driver: X: loaded: modesetting gpu: i915
resolution: 3200x1800~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 620 (KBL GT2) v: 4.6 Mesa 22.0.5

> FWIW, if you like to compare or post your own details: 'inxi' can be installed on Ubuntu with `apt install inxi` and I believe it's in Debian as well.
>

Looks like it might be installed by default on Ubuntu - at least I do
not recall installing it, but it is present!

> Note that I'm currently running the Gnome/Wayland desktop ("Gnome 3.36.9"). Switching to "fullscreen" shows a kind of "animation", obviously updating the screen many times. Maybe this animation makes it work? Ian, how does your failing system(s) switch to fullscreen, is it all in one step, or is it animated?
>

I think that it is animated, but as a very swift animation, certainly
not anything fancy; it does not look like an instant snap to the new
size, at least not to my old eyes...

> BTW: I just checked that the OP's animated GIF shows the switch to fullscreen in one step (not animated), maybe the (mis)behavior depends on the desktop (WM)?

That's an interesting point - the WM is presumably involved in sending
(at least some of the) redraw events to the application, so different
WM may manifest different behaviour.
The Mint distros may well differ from stock Ubuntu in this area... not sure.

I'm not sure the OP's GIF necessarily shows all the frames - I was
using a screen-capture tool the other day and it missed out (perhaps
on purpose?) a lot of the window and menu animation frames, so the
captured result was *timed* the same as the original but had far fewer
intermediary states, as it were.

[lukas...@outlook.com]

Thanks for the all the replies and suggestions!

Trying to answer all the questions that came up:

• The output of inxi -SG (with the appropriate environment variables to select the desired GPU)
  __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia inxi -SG
  System:
    Host: laser Kernel: 5.4.0-137-generic x86_64 bits: 64 Desktop: Xfce 4.14.2
    Distro: Ubuntu 20.04.5 LTS (Focal Fossa)
  Graphics:
    Device-1: NVIDIA driver: nvidia v: 525.60.13
    Device-2: ASPEED Graphics Family driver: ast v: kernel
    Display: x11 server: X.Org 1.20.13 driver: modesetting,nvidia
    unloaded: fbdev,nouveau,vesa resolution: 3000x2000~50Hz
    OpenGL: renderer: NVIDIA RTX A5000/PCIe/SSE2 v: 4.6.0 NVIDIA 525.60.13
•  The system is accessed through Remote Desktop, with the Ubuntu machine running xrdp. If I login locally, it does appear to be working as expected.
• The window is maximized instantly, i.e. there is no animation going on as far as I can tell.
• FLTK version is 1.3.8, downloaded from the website (this link)
• Desktop environment according to "echo $XDG_CURRENT_DESKTOP" is xfce, Window manager according to "wmctrl -m" is xfwm4
• Using FLTK version 1.4.x (from here) shows the same behavior, and adding  FLTK_BACKEND=x11 also changes nothing
• Disabling double buffering via the button in the example completely breaks it for me, the GL part of the window is never redrawn in that case (until double buffering is reenabled at least)
• As for manually issuing a delayed redraw() call: Can anyone suggest a "nice" way of doing this?

Also: In case I forgot to answer a question or if I should test something else, please let me know

[imm]

On Mon, 30 Jan 2023 at 17:15, lukas... wrote:
>

> The output of inxi -SG (with the appropriate environment variables to select the desired GPU)
> __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia inxi -SG

Though this may not matter, as I thought the xrdp implementation
mostly ignored the GPU anyway?
That may no longer be the case, of course...

> The system is accessed through Remote Desktop, with the Ubuntu machine running xrdp. If I login locally, it does appear to be working as expected.

OK - RDP, this may be important.

If you log in locally, it works "normally" in both single-buffered and
double-buffered modes? Or only in one of the modes?

But via RDP it always fails?

What mode is your xrdp running in? Is it xorgxrdp mode or is it
VNC-forwarding mode?

TBH, I'm not a huge fan of RDP, even between Windows machines, as I've
had it do weird stuff to me on many occasions.
For remoting to a Linux box I always prefer X11 "natively" (there are
adequate Windows-hosted X11-servers now, or WSL2 can do it) or VNC,
because they bite me less often.
But none of them Just Work all the time...
(between Windows boxes, VNC usually works...)

[lukas...@outlook.com]

> Though this may not matter, as I thought the xrdp implementation
> mostly ignored the GPU anyway?
> That may no longer be the case, of course...

I set the GPU to enable OpenGL <-> CUDA interop which I need for my actual application, so I thought I'd include the same settings here to not misreport anything. I also just ran the example without the  __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia environment variables, and it does appear to work properly in that case (both maximizing and double/single buffering). The issue is that the renderer reported by the example changes to "GL_VERSION=4.5 (Core Profile) Mesa 21.2.6" (with those environment variables set it's "GL_VERSION=4.6.0 NVIDIA 525.60.13"), and that means I can't use OpenGL <-> CUDA interop later on (so this mode doesn't work for me).

> If you log in locally, it works "normally" in both single-buffered and

> double-buffered modes? Or only in one of the modes?

Logging in "normally" (i.e. no RDP), both buffering modes work normally, yes.

> What mode is your xrdp running in? Is it xorgxrdp mode or is it
> VNC-forwarding mode?

The session type is set to Xorg (I quickly tried to change it to Xvnc, but I couldn't manage to log in)

So, as a quick summary: The failure only happens if I log in via RDP (xrdp/Xorg), and only if I force it to use the Nvidia GPU using " __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia". In that case, single-buffering doesn't work at all, and double-buffering doesn't redraw properly when maximizing the window. In all other cases, both buffering modes and maximizing work as expected as far as I can tell.

[lukas...@outlook.com]

In the meantime, I have tried to find a workaround, but no luck so far. My best attempt currently is subclass Fl_Window and add the following override of the resize method:

    void resize(int X, int Y, int W, int H) override
    {
        add_output("Resize: %d x %d @ %d x %d\n", W, H, X, Y);
        Fl_Window::resize(X, Y, W, H);
        redraw();
        Fl::check();
    }

This manages to call the draw method of the Fl_Gl_Window at a point where the size is updated correctly, but somehow it's not enough. Any suggestions for how to force a "full" redraw, similar to what normal window resizing does?

[Manolo]

You could try to add this static function

static void delayed_redraw(void *data) {
  ((Fl_Window *)data)->redraw();
}

and to override your GL3 window's resize method as follows:

  void resize(int x, int y, int w, int h)  override  {
    Fl_Gl_Window::resize(x, y, w, h);
    Fl::add_timeout(0.01, delayed_redraw, this);
  }

[lukas...@outlook.com]

I have finally found a workaround that seems to do the trick: As before, I have subclassed the Fl_Window class to override the resize method. The following sequence of redraw and check calls seems to work:

    void resize(int X, int Y, int W, int H) override
    {

        Fl_Window::resize(X, Y, W, H);
        redraw();
        Fl::check();

        glWin->redraw();
    }

Here, glWin is a pointer to the SimpleGl3Window instance. Removing any of the lines or reordering them too much breaks this workaround, but I have no idea why this precise sequence works.