Slight flicker when opening Qt application menus in qubes with gui-events-max-delay feature set

[ArrayBolt3]

How to file a helpful issue

Qubes OS release

R4.3

Brief summary

When using Qt applications, qubes which have the gui-events-max-delay feature set to a non-zero value may exhibit flickering when opening a menu in an application's menubar. The flicker doesn't occur 100% of the time, and it isn't massive, but it's definitely there. For unknown reasons this flicker does not appear to occur in GTK applications like Thunar and xfce4-terminal, but does occur in multiple Qt applications (qterminal, pcmanfm-qt).

Steps to reproduce

• Launch xfce4-terminal in an anon-whonix AppVM (since it will have gui-events-max-delay set to 100 by default).
• Install qterminal.
• Run qterminal.
• Click on one of the items in the application menu bar, such as "File".

Expected behavior

Menu should immediately appear and not flicker.

Actual behavior

Menu appears, then seems to very briefly vanish, then re-appear (flicker).

Additional information

So far I've reproduced this on Whonix-Workstation 18 and Debian 13. Setting gui-events-max-delay to 0 causes the flicker to stop.

[ArrayBolt3]

@andrewdavidwong Please assign this to me as I am the primary author of the gui-events-max-delay feature in qubes-gui-daemon. I should look into why exactly this is happening and hopefully fix it.

[ArrayBolt3]

I tried comparing the GUI daemon logs of an anon-whonix VM with event buffering enabled with a Fedora 42 VM with event buffering disabled, after putting both VMs into debug mode (qvm-prefs VM debug True). The only thing that stood out to me was that there are some events sent from the X server in dom0 to the X clients in domU that are not a direct result of the user doing something resulting in input going to the application. In particular, ConfigureNotify seems to be sent from server to client without an input event triggering it. Right now we're buffering and delaying all X11 events coming from the server, including these kinds of events, which might be the trigger. Even if it's not the trigger though, it seems like it would be worthwhile to identify the events that are essentially implementation details of X11 and omit those events from buffering; a quick skim through https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html makes me believe ReparentNotify, ConfigureNotify, and MapNotify could all stand to be left unbuffered, since the documentation states something like "The X server generates this event type whenever a client application does XYZ" for all three event types. "Expose" and "PropertyNotify" both look dangerous to pass through in this way, and I'm not sure about "ClientMessage".

[marmarek]

ConfigureNotify is likely related to the problem, it informs the VM when the window gets moved/resized (either by the user directly, or by the window manager). If that event is delayed, the window (on the VM side) will have mismatching size/position for a moment, which is possible to result in flickering. That said, I'm not sure why it would happen for menus - those are not really positioned by the window manager - it's the application dictating size/position. But maybe Qt is creating those in multiple steps and delaying the event interferes with that?

[ArrayBolt3]

I believe Qt does draw menus in multiple steps. If I SSH into a Kicksecure 18 machine with X forwarding enabled, there is a visible initial draw and then second draw done when each menu pops up, resulting in a flicker of sorts. That level of flicker is acceptable, but the flicker I see with event buffering also includes the menu's "subwindow" resizing rapidly, which is weird and distracting.