Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

context.getCurrentTextureView() blocks when window is obscured #4

Open
mreinstein opened this issue Feb 1, 2025 · 5 comments
Open

Comments

@mreinstein
Copy link

@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
Copy link
Author

more details:

macos 15.2
[email protected]
@kmamal/[email protected]
@kmamal/[email protected]

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
Copy link
Owner

kmamal commented Feb 11, 2025

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

@mreinstein
Copy link
Author

still seems to be happening, with these versions:

macos 15.3.1
[email protected]
@kmamal/[email protected]
@kmamal/[email protected]

@kmamal
Copy link
Owner

kmamal commented Feb 19, 2025

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants