-
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
Spec glrc.drawingBufferStorage. #3222
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is pleasingly small and gives applications the chance to feature detect. Personally I like this approach. Other opinions / feedback?
A few questions.
@@ -1671,6 +1703,7 @@ <h3><a name="WEBGLRENDERINGCONTEXT">The WebGL context</a></h3> | |||
|
|||
const GLenum RGBA4 = 0x8056; | |||
const GLenum RGB5_A1 = 0x8057; | |||
const GLenum RGBA8 = 0x8058; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some WebGL conformance tests like conformance/context/constants-and-properties.html and conformance2/context/constants-and-properties-2.html (and maybe others) will have to be updated for this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that's on the list of test changes that we'll need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ccameron-chromium points out in https://chromium-review.googlesource.com/c/chromium/src/+/4887172 that it's necessary to add RGB8
to WebGL 1.0 too, because {alpha:false}
contexts use this as drawingBufferFormat
even though drawingBufferStorage
can't be called for such contexts afterward.
specs/latest/1.0/index.html
Outdated
@@ -1728,6 +1761,8 @@ <h3><a name="WEBGLRENDERINGCONTEXT">The WebGL context</a></h3> | |||
sequence<DOMString>? getSupportedExtensions(); | |||
object? getExtension(DOMString name); | |||
|
|||
undefined backbufferStorage(GLenum sizedFormat, unsigned long width, unsigned long height); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar for this new method.
similar to <code>renderbufferStorage</code> as used on Renderbuffers. | ||
|
||
Clearing behavior is equivalent to setting <code>HTMLCanvasElement.width</code> and <code>HTMLCanvasElement.height</code>, followed by changing the backbuffer format. | ||
This method respects <code>WebGLContextAttributes.antialias</code>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can the user know (aside from calling gl.getError, which is discouraged) that the setting actually took effect? Should we add a new read-only property alongside drawingBufferWidth
and drawingBufferHeight
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can't tell today for textures or renderbuffers, so I'm not super worried about going above-and-beyond for backbuffers.
@lexaknyazev @ccameron-chromium please review this version of this functionality and see how you like it compared to #3220 . (I don't have the ability to explicitly add you as reviewers.) Thanks. |
I haven't thought on this too deeply, but it seems like quite a nice approach. I initially thought the dynamicness would be scary - but the semantic I imagine is simply "throw out the drawing buffer you allocated for this frame (if any) and replace it with new blank one with this format". As long as implementations can get that texture to the compositor, that's great. nit: The "backbuffer" naming makes the "back"ness central when it's not necessarily relevant (though with the semantic above, maybe it is, since you couldn't have that semantic on a frontbuffer...?) Could be "default framebuffer", "default framebuffer color attachment", "drawing buffer", ? |
I'm definitely being cheeky and saying "backbuffer" when I mean "default framebuffer", but "default framebuffer" is relatively poorly understood, I believe. I can s/backbuffer/default framebuffer/ though, it's technically more correct. |
Actually, since I would like to avoid I like this as-is, because I feel like practically 100% of people will understand what's going on here, even without a good background in WebGL details. |
c81e9fa
to
8b7b88a
Compare
Looks great overall. Couple thoughts:
|
I think all combinations should be valid. They are all equally feasible technically, but have varying degrees of usefulness. Most APIs (Metal, Vulkan, D3D) allow all combinations. Would we want to include the color space as an argument to backbufferStorage, too? (I'm bringing the question up for completeness -- I have no opinion on that topic. For WebGPU, the plan is to add color space to GPUSwapChainDescriptor, which is vaguely analogous. Should we leave open the possibility of adding it as an optional argument?) |
TBH moving all the way to a WebGLSwapChain sounds better. I'll see what that looks like. |
And +1 on keeping colorspace and format orthogonal, even if some combos are bad ideas. (rec2020 rgba8) |
Moving to WebGLSwapChain would be extremely cool, but I worry it would make the road to implementation a lot longer. Seems ideal to do things incrementally: design something like backbufferStorage() now that can still be used in a future with a WebGLSwapChain and maybe later even headless WebGL contexts. On the topic of WebGLSwapChain, I bet WebGPU's GPUCanvasContext could serve dual purpose. Note the GPUDevice isn't bound to the GPUCanvasContext until GPUCanvasContext.configureSwapChain.
or something. |
Thanks @kainino0x for your input. Per discussion today with @jdashg and @ccameron-chromium - we're in agreement that adding a swap chain concept to WebGL at this late stage in its evolution is too much to add. Here's the current plan:
Still discussing how |
specs/latest/1.0/index.html
Outdated
Respecify the size and format of the backbuffer, | ||
similar to <code>renderbufferStorage</code> as used on Renderbuffers. | ||
|
||
Clearing behavior is equivalent to setting <code>HTMLCanvasElement.width</code> and <code>HTMLCanvasElement.height</code>, followed by changing the backbuffer format. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec talks about clearing behavior here.
I presume this means that after the developer calls backbufferStorage
, subsequently querying HTMLCanvasElement.width
, HTMLCanvasElement.height
, drawingBufferWidth
and drawingBufferHeight
will return the values passed to `backbufferStorage'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, modulo the same limitations the browser already enforces. Recall that drawingBufferWidth
and drawingBufferHeight
may be clamped due to platform limitations. The intent here is to make this new API behave exactly the same as resizing the HTMLCanvasElement
or OffscreenCanvas
, to avoid adding yet another behavior to the web platform.
specs/latest/1.0/index.html
Outdated
Respecify the size and format of the backbuffer, | ||
similar to <code>renderbufferStorage</code> as used on Renderbuffers. | ||
|
||
Clearing behavior is equivalent to setting <code>HTMLCanvasElement.width</code> and <code>HTMLCanvasElement.height</code>, followed by changing the backbuffer format. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the user first calls backBufferStorage
and subsequently sets the HTMLCanvasElement.width
and HTMLCanvasElement.height
attributes, will the default framebuffer be resized to the last format passed as the sizedFormat
parameter? Or will the default framebuffer be resized to whatever the default format the user agent decided when it first allocated the default framebuffer? The former seem preferable but I don't have a strong opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll use the last format passed in to backBufferStorage
- which per the last WebGL WG meeting will be renamed to drawingBufferStorage
in the next iteration of this proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Jeff for putting together and revising this; it looks good to me!
I'm really excited about trying this out! How do you think we should move forward? Land this and put implementations behind flags, for example?
</p> | ||
<p> | ||
In WebGL 1.0, <code>RGBA16F</code> requires the extension <code>EXT_color_buffer_half_float<code>. | ||
In WebGL 2.0, <code>RGBA16F</code> requires the extension <code>EXT_color_buffer_float<code>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EXT_color_buffer_half_float's legal in WebGL 2.0 contexts now - to support iOS devices specifically. It would be better to say that WebGL 2.0 requires either EXT_color_buffer_float or EXT_color_buffer_half_float.
specs/latest/1.0/index.html
Outdated
<dd> | ||
The current effective format of the drawing buffer. | ||
Initially <code>RGBA8</code> or <code>RGB8</code> for <code>alpha:true</code> and <code>alpha:false</code> respectively. | ||
The actual height of the drawing buffer. May be different from the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This text and below's accidentally duplicated.
how do does this work with |
Good question. Fortunately, |
Is there anything more that we need to do in order to get this merged? |
@kdashg told me on chat it was OK if I merge this after final cleanup, so doing that now. |
This PR seems to be rendered on https://registry.khronos.org/webgl/specs/latest/1.0/ but not on https://registry.khronos.org/webgl/specs/latest/2.0/. Can the WebGL 2 spec be updated, too? |
It is defined on
(Same as for many other entrypoints.) |
ahhh of course! Thank you!! Sorry for the noise. |
An alternative to #3220.