Closed Gordon-F closed 3 years ago
Is there a particular reason we want to treat WebGL as a distinct target for the purposes of the compatibility checks?
WebGL
not always equals OpenGL ES
. These changes should help properly check WebGL combability info. If we don't have WebGL
as a distinct target we should set current Version::new_embedded
(3.0/2.0) as a WebGL
(1.0/2.0) somehow.
Also this changes can be a part of https://github.com/gfx-rs/wgpu/issues/1244.
WebGL not always equals OpenGL ES
I know this is true, but the question is whether these differences are important for our GL backend. Could you give an example of where this distinction would make sense?
If we don't have WebGL as a distinct target we should set current Version::new_embedded (3.0/2.0) as a WebGL (1.0/2.0) somehow.
Right, I don't think this is going to be too hard.
I know this is true, but the question is whether these differences are important for our GL backend. Could you give an example of where this distinction would make sense?
Ok, Agree with you. They are only theoretically different.
If other code in PR is ok, my plan:
new_webgl
from VersionWebGL1
== OpenGL ES 2.0
and WebGL2
== OpenGL ES 3.0
internallyTemporarily convert PR to draft because latest changes (WebGL 2.0
== OpenGL ES 3.0
) panic in cube
example.
Code panic here: https://github.com/gfx-rs/gfx/blob/4b63f30807204b22f1ba52bb3356e69e19fb896a/src/backend/gl/src/lib.rs#L552-L559
I don't know how we can enable FRAMEBUFFER_SRGB
for WebGL target 🤔
Ok, we don't need to enable FRAMEBUFFER_SRGB
on embedded targets. Should be ready to merge.
Fixes #issue PR checklist:
make
succeeds (on *nix)make reftests
succeeds