context.getCurrentTextureView() blocks when window is obscured

[mreinstein]

@kmamal when the sdl + gpu window is completely obscured (not minimized), calling context.getCurrentTextureView() is blocking or takes a really long time (> 1 second where normally it's very quick).

This really wreaks havoc on my main loop because the thread screeches to a halt. Is there any way to fix this? Or barring that, detect when the sdl window is not showing? window.visible doesn't change it's value if the sdl window is not minimized but fully covered by other windows.

[mreinstein]

more details:

macos 15.2
node@22.13.1
@kmamal/gpu@0.1.3
@kmamal/sdl@0.10.10

I'm also running 2 sdl+gpu window instances simultaneously, in totally separate node processes.

I haven't tried to distill this down into a minimal test case but I'm happy to help with that in any way, please let me know.

[kmamal]

Curious if this is also stil a problem with the new version?

[mreinstein]

still seems to be happening, with these versions:

macos 15.3.1
node@22.14.0
@kmamal/gpu@0.1.5
@kmamal/sdl@0.10.12

[kmamal]

I am able to reproduce it but I'm not yet sure what to do about it.

As a workaround could you maybe listen for the window's 'blur' event? There are no events for the window getting covered, but losing keyboard focus might serve as a proxy.

[mreinstein]

could you maybe listen for the window's 'blur' event?

I suppose that could be a semi-nuclear option. The only downside there is there are cases where the window is still visible even though it's blurred (e.g., I have 2 clients running side by side on my development environment for testing) Though this is probably not a common/likely usage pattern for the game. freezing the rendering is better than blocking the entire game loop I suppose. :)

able to reproduce it

Do you have a sense of what the underlying cause is? My assumption is some lower level call is blocking somewhere when the OS detects none of the pixels of the window are visible.