SimpleBrowser seems to freeze when resuming from screen saver

[Willy K.]

We are currently analyzing an issue with our WebEngine based browser on Windows where it seems that the application freezes when display is turned on again after it was idle for some time. The issue occurs randomly and it is quite tricky to tell about conditions - at some times it happens quite often, at other times it doesn't occur for hours (or we didn't recognized that in mean-time).

We say "seems" since it looks that the screen will not be updated, e.g. animations are stopped, actions on web page elements like clicking/touching buttons are not processed etc. Remote debugging using the Remote Inspector has shown that the application is running as usual, e.g. the actions on the buttons are processed, but the screen at the device were the browser is running does not change.

However, when the window looses the focus, e.g. due to a task switch, the application continues and works as usual. It seems to be related to hardware too: We observed this behavior on Kabylake and Tigerlake based systems (7th/11th generation of Intel CPUs), but not on the Skylake based systems - at least until yet.

The latter let some people think that the issue is related to drivers, but we also tried the same with Chrome, Firefox and Edge and there is no problem with that. However, it seems to be common that browser interrupt GUI activity during the screen saving period, we observed this with the browser mentioned above too.

Currently we try to reduce the application to a minimum DOM that is required to reproduce the issue as easy as possible, but the current opinion is that it seems that is related to SVG in DOM that is manipulated at runtime using JavaScript. We can also tell that this issue can be observed with the "SimpleBrowser" example, and we tried with QT V5.12.9/, V5.15.1 and also V6.4.2. O/S is WIndows 10 Enterprise 64bit, Version 21H2, the application was built using VS2017 resp. VS2019 for V6.4.2. We also noticed that the application also returns back to normal operation when a tooltip is display after the mouse hovers over the UI elements of the SimpleBrowser's tool bar.

We already tried to add chromium-flags like "disable-gpu", "disable-gpu-rasterization" but no success, and we currenlty have no more ideas what else we can do.

So we ask you if you have any ideas what is going wrong here and maybe some tipps how we can get rid of this issue?
Have much thanks in before,

Yours Willy K.

[Willy K.]

We fear that much knowledge about how the Qt framework produces the graphics as well as much time will be required to determine the core of this issue. So we thought about workarounds to get rid of that, by meaning of doing something that causes a "refresh" of the window when the display resumes from standby. During our recherche, we found following (to be done in the QMainWindow instance):

qApp->processEvents();
update();

Unfortunately that didn't work (what surprise...).

hide();
show();

or

resize(...); // Change width and/or height for 1px or so

Both of them worked, where hiding/showing the window may result in that users may see what is behind the browser (for a very short moment, of course). However, both of them seem to be a very amateurish way to do this.

Do you have any other ideas how to force the graphics to be refreshed?
Have much thanks in before,

Yours Willy K.