-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Feasible to enable OpenGL as a fallback instead of an override? #457
Comments
I think that would be great, but only if the |
Is there any particular reason you are interested in having If you do not need image or SVG support, why not ship I guess the question here is: if we change |
I have a few reasons, roughly in order of importance: |
I know, "OpenGL is dead". This is the main reason
You need to enable the
Fair enough! However, keep in mind these newer technologies may not be able to satisfy all your needs right away. Just to be clear, I do believe we should eventually offer rendering fallbacks. Specifically:
We may be able to simply rely on However, I feel it is a bit early to work on this as our rendering model still needs to improve a lot and tackling this could pin the current design. |
That's good to know about |
Fixed by #1748. |
If I understand correctly, the
glow
feature makes the OpenGL support totally override the default WebGPU support. Would it be feasible to have some way of trying both in a single build? As in, try WebGPU first, but if Vulkan/etc isn't available on the user's system, then try OpenGL as a fallback. Right now, I'm producing two separate builds (a main version with WebGPU and a secondary version with OpenGL in case people need it), but I was thinking it might be nice to have an all-inclusive build so users don't have to worry about which one to use.The text was updated successfully, but these errors were encountered: