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
Aquarium has been using GLFW for window system binding. This currently works for the D3D backend thanks to the GLFW_NO_API and native access tricks. However, GLFW advertises itself as a library for OpenGL, OpenGL ES and Vulkan development, which makes the D3D use case somewhat weird. Taking the planned WebGPU port in consideration, it also sounds too hard or even impossible to extend Emscripten's GLFW simulation layer for the related APIs, so the only feasible solution there is to use Emscripten primitives instead. The proposal is to replace GLFW with a home-made window system binding implementation by:
Introducing a window system abstraction layer, and making GLFW a backend of it
Implementing the Win32 backend
Implementing the X11 backend
Implementing the Cocoa backend
Implementing the Emscripten backend
Dropping the GLFW backend
And a Wayland backend may also be needed in the future, so that's why the proposal tends to avoid naming the backends using OS names.
The text was updated successfully, but these errors were encountered:
Glfw was convenient because it's compatible with different os and it helped to resize the window. It's quite large effort to write all of the window system and resize work by ourselves.
Aquarium has been using GLFW for window system binding. This currently works for the D3D backend thanks to the
GLFW_NO_API
and native access tricks. However, GLFW advertises itself as a library for OpenGL, OpenGL ES and Vulkan development, which makes the D3D use case somewhat weird. Taking the planned WebGPU port in consideration, it also sounds too hard or even impossible to extend Emscripten's GLFW simulation layer for the related APIs, so the only feasible solution there is to use Emscripten primitives instead. The proposal is to replace GLFW with a home-made window system binding implementation by:And a Wayland backend may also be needed in the future, so that's why the proposal tends to avoid naming the backends using OS names.
The text was updated successfully, but these errors were encountered: