You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the game's FPS is locked to the screen refresh rate (typically 60 FPS), which delays user input responses and makes gameplay less smooth. I'm planning to port a larger game to Deno, but this issue makes me hesitant about it.
I’ve noticed that surface.present() blocks the main thread, limiting the FPS to 60. When I remove surface.present(), the FPS increases to over 200(but the rendered result is not displayed on the screen).
Suggestion
One possible approach could be to create the surface in the main thread (since surface creation must happen in the main thread due to a wgpu issue), and then transfer it to a web worker. In the worker, we would call render() and surface.present(), while keeping input processing and game logic in the main thread:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Is there any plan to implement OffscreenCanvas for WebGPU?
Background
I have ported a small game to Deno using WebGPU:
https://github.com/Mutefish0/rega/tree/main/celeste
Currently, the game's FPS is locked to the screen refresh rate (typically 60 FPS), which delays user input responses and makes gameplay less smooth. I'm planning to port a larger game to Deno, but this issue makes me hesitant about it.
Here’s a snippet of my code:
I’ve noticed that surface.present() blocks the main thread, limiting the FPS to 60. When I remove surface.present(), the FPS increases to over 200(but the rendered result is not displayed on the screen).
Suggestion
One possible approach could be to create the surface in the main thread (since surface creation must happen in the main thread due to a wgpu issue), and then transfer it to a web worker. In the worker, we would call render() and surface.present(), while keeping input processing and game logic in the main thread:
In the web, there’s OffscreenCanvas, which achieves a similar purpose. Here’s a WebGPU example.
I've also created a proof of concept in my fork, and the results look promising:
I’d love to hear your thoughts on this idea :)
Beta Was this translation helpful? Give feedback.
All reactions