Gfx.show presents white/black pattern before starting some times after closing too.

[Garyfallidis]

Hi @almarklein and all,

Thank you for developing this great project. We are working to use pygfx in the fury.gl project. Here is small glitch that we found:

On Windows 10 after running the following snippet I get a no responding window.

import pygfx as gfx
import pylinalg as la

cube = gfx.Mesh(
    gfx.box_geometry(200, 200, 200),
    gfx.MeshPhongMaterial(color="#336699"),
)

rot = la.quat_from_euler((0, 0.01), order="XY")

def animate():
    cube.local.rotation = la.quat_mul(rot, cube.local.rotation)

if __name__ == "__main__":
    gfx.show(cube, before_render=animate)

This happened first after I closed the window.

Python 3.9.7 Numpy 1.26.1

Now after looking deeper into this. The issue was taking place primarily in the beginning of the visualization. Sometimes happened at the end too. After closing. But less often.

So what makes the white/black pattern appear?

[Korijn]

You have two if __name__ == "__main__": gfx.show(...) entrypoint statements in your script. This is highly unconventional, I don't think I've ever seen something like that before.

I guess after the first call to gfx.show returns (which is when you close the window) the second call breaks the app, which is something we can fix. I've updated the title to reflect the root cause.

However your script definitely only needs one call, and that should fix the issue as well.

It looks like a copy paste mistake, could that be what has happened here?

[Garyfallidis]

No this was simply a copy paste issue @Korijn

The issue persists at the opening and closing of the window.

[Garyfallidis]

There is some delay there ... to initialize the window. I can check tomorrow in Linux too. Maybe this is already resolved on master. Currently testing last release version.

[Korijn]

Which version of glfw and wgpu-py are you using?

[almarklein]

This happens after I close the window.

I'm a bit confused. Does the window become unresponsive right away when running the script, or only after closing it?

We recently made some changes in the logic related to closing a glfw window in wgpu-py. These are present in the latest wgpu-py release.

edit: although that wgpu-py release is more recent than the latest pygfx release, they should work fine together

[Garyfallidis]

Hi @almarklein and @Korijn I updated the description. So, what creates the white/black pattern when calling show?

[Korijn]

Which version of glfw and wgpu-py are you using?

Can you answer this question?

Then I can try to reproduce.

[almarklein]

what creates the white/black pattern when calling show?

I think the white square represents the original (default?) size of the Window. This kind of glitch is likely related to the GUI's event loop not running, so glfw is never actually performing any draws. Therefore I think this issue is related to the event-loop (asyncio in this case) somehow.

If it happens when the window is supposed to be closed, it might be related to wgpu thinking that the window is closed, and thus not performing any draws, even though it's not actually hidden.

Now after looking deeper into this. The issue was taking place primarily in the beginning of the visualization. Sometimes happened at the end too. After closing. But less often.

Is this all that the window shows, or has it also shown the cube and then failed into showing what we see on the screenshot? What do you mean with "after closing", when you hit the cross on the window, it does not go away but shows this instead?

[Garyfallidis]

The cube was shown too yes. After the white/black opening theme :) . I do agree that this is most likely related to glfw as we did not see the issue with with qt.

[Garyfallidis]

A bit unfortunate, because it so much easier to release software with glfw rather than qt.

[Korijn]

Which version of glfw and wgpu-py are you using?

[Garyfallidis]

glfw 2.5.5 wgpu 0.13.1

[almarklein]

I initial impression was that the screenshot was all that was shown 😅, but I now understand that it's only for a brief time, either at the start or right after closing.

I think I have indeed observed the square briefly in startups too. I will try and reproduce that. There is of course a window of time between when the window is created and the first draw takes places. But I agree that the window being all black would be better :)

The glitch at close-time can perhaps be resolved by hiding the window before destroying it.