qt example flashing

[Vipitis]

Hey, I was looking into the async branch and noticed odd flashing in the qt examples (both qt_app.py variants). See the video:

qt_app_flashing.mp4

I bumped PySide6 to 6.10.1 and saw it happen on main - then bisected it to d4df1c9 which is the merge for #169. This is with python 3.12.9 on windows.

Not awake enough to look into it right now, but wanted to file the issue so I don't forget.

[almarklein]

mmm, I cannot reproduce the flicker. Used Windows 11 with PySide updated to 6.10.1

[Vipitis]

it also didn't happen on my laptop, so it might have to do with the monitor refresh rate on my other system... I will find some time to dig around - but might be a week.

[Vipitis]

so it's also happening on the cube_qt.py example and seems to get worse with higher fps. this clip is only recorded at 30fps, but on my monitor really crazy, almost lowering the intensity.

qt_worse.mp4

but even at extremely low fps

qt_low_fps.mp4

so it's not the fps but something else. Maybe I can try and figure out what the difference is with my laptop not showing this. I tried to get into it with the debugger and it looks like the call to present does present the image to the gui just fine.
Now during this line I can't step into anymore and it gets white

rendercanvas/rendercanvas/qt.py

Line 238 in 2fe764e

app.exec() if hasattr(app, "exec") else app.exec_()

and I believe this is the QT loop taking over.

[Korijn]

Maybe it's qt painting before the frame is ready?

[Vipitis]

that sounds plausible. I have not been looking at the stack trace and I didn't run with async debug so the sequence might be incorrect when stepping. Maybe I get it working with tracing, otherwise just some print statements to try and figure out what's happening.

[almarklein]

This is on main, right? edit: also on the async-bitmap branch? That branch touches much of the code that was also affected by #169, although I don't see yet how that might have broken it.

[almarklein]

Maybe it's qt painting before the frame is ready?

Yeah it looks like Qt is painting a widget background. So either Qt painting over the cube, or the presentation of the cube image is canceled for some reason ... or they just fight for it.

@Vipitis Can you confirm that #169 introduced this behavior?

And what about the async-bitmap branch?

You can also try 'bitmap' vs 'screen' present methods.

I'll also try on a different Windows laptop later today.

[Vipitis]

i saw this on the async branch and also main. It was fine on main before the commit I mentioned at the top.
I can try other combinations later today or in a couple of days.

I can try a different system too. Maybe it's to do with different GPUs blocking on present versus not?

[Vipitis]

Okay, tried a different laptop (Intel iGPU, I also have an Intel dGPU in my machine at home). And it happened here too. bad on main and good on 2.5.2

Will revisit the laptop where it wasn't a problem and maybe see if it used Nvidia dGPU or Intel iGPU... will also test Vulkan vs dx12 vs openGL but that has to wait a bit.

[almarklein]

I just ran into this on a Linux machine. Indeed when using intel, not nvidia for both intel and nvidia, and when using 'screen' present.

edit: same machine on windows: flashing only with intel

[almarklein]

Ok, I know the cause of the problem: the line self.setAttribute(WA_PaintOnScreen, self._present_to_screen) was accidentally removed in #169. Turning it back at the same place, where the present info dict is returned, does not seem to work. Earlier it was decided at __init__ what present method was used, now it's decided later. The paintEvent() overload is also part of the story. Looking into it.

[almarklein]

Try #174

[Vipitis]

it seems to do it.

I tested on my laptop where it wasn't a problem and switching to low power (intel iGPU) did also cause it. checking out the flicker branch fixed it there.

On my computer with intel dGPU there is no iGPU, so I can't compare them. But switching to the flicker branch definitely worked there too.

additionally I changed the graphics backend to D3D12 and that didn't show it anywhere... so it seems only show up with Vulkan maybe. Apparently the call to present can be blocking in some configurations (backend, driver, surface, present mode) but the documentation isn't clear either: https://docs.rs/wgpu/latest/wgpu/struct.SurfaceTexture.html#method.present

[almarklein]

Thanks for testing!

Apparently the call to present can be blocking in some configurations (backend, driver, surface, present mode) but the documentation isn't clear

Different backends / os's indeed differ on where they block. Some on getting the current texture, some when presenting it. On questions on when what method is used the answer something like 'it depends' :)