-
Notifications
You must be signed in to change notification settings - Fork 669
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
RGB(A)8 renderbuffers on WebGL 1.0 #3475
Comments
The proper way to do this would have been to have OES_rgb8_rgba8 as an extension. I know this is a late-breaking change, but it would nicely close of this corner of issues. (and having RGB8 but not RGBA8 I'm sure always surprised people) This would be feature-testable during roll-out because gl.RGBA8 will be FWIW, renderbuffers don't take gl.RGB, and require the sized RGB8 enum. DEPTH_STENCIL is an exception that we don't want to emulate here. |
Discussed in WebGL conference call of 2022-08-11. There was consensus not to add an |
This looks like a quirk existing due to historical reasons but may still be worth clarifying.
RGBA4
/RGB5_A1
/RGB565
internal formats for renderbuffer color attachments. 8-bit renderbuffers are provided only byOES_rgb8_rgba8
.EXT_sRGB
extension is based onGL_EXT_sRGB
that requiresOES_rgb8_rgba8
.Given 1-3, it seems quite counter-intuitive that WebGL 1.0 renderbuffers can have
SRGB8_ALPHA8_EXT
or floating-point formats but notRGBA8
.At the very least, we should add a note to
EXT_sRGB
clarifying the ignored dependency. Optionally, WebGL 1.0 renderbuffers may be allowed to haveRGB8
/RGBA8
internal formats (aliased as their unsized counterparts, similar toDEPTH_STENCIL
) as ifOES_rgb8_rgba8
is always enabled.Maybe related: #3364.
/cc @kenrussell @kdashg
The text was updated successfully, but these errors were encountered: