Intent to Ship: WebGL drawingBufferStorage

Christopher Cameron

unread,

Nov 27, 2023, 4:20:37 PM11/27/23

to blink-dev, Ken Russell

Contact emails

ccam...@chromium.org

Explainer

None

Specification

https://github.com/KhronosGroup/WebGL/pull/3222

Summary

WebGL allows rendering into textures and renderbuffers of many different pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by default. This feature allows WebGL to configure the pixel format of this drawing buffer. This feature enables WebGL developers to: * avoiding an an extra copy convert their rendering to the default drawing buffer pixel format * draw content that has a more than 8 bits of precision The latter feature unlocks several additional applications * very wide color gamut content without loss of precision * medical applications which require >8 bits of precision * high dynamic range applications (when available)

Blink component

Blink>WebGL

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None.

Gecko: Positive Feature authored by Mozilla.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/278)

Web developers: Positive Positive feedback from several high profile web developers - 3D engines that use physically based rendering - image editing formats (especially for HDR) - medical imaging applications (which require >8 bit precision)

Other signals: This feature's specification was authored by Mozilla.

Ergonomics

None.

Activation

No.

Security

None.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

No additional debugging support should be needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

The underlying technology (floating point textures) has almost universal support.

Is this feature fully tested by web-platform-tests?

No

This feature is fully tested using WebGL conformance tests, which has been checked in.

Flag name on chrome://flags

Finch feature name

None

Requires code in //chrome?

False

Availability expectation

Feature is available on Web Platform in less than a year following launch in Chrome.

Adoption expectation

Several specific partners have been using this feature being chrome://flags' "experimental web platform features", and intend to adopt this as soon as it is supported.

Estimated milestones

Shipping on desktop

122

Shipping on Android

122

Shipping on WebView

122

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5146687245123584

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj-HFt%3Dk5NBHb5SyNT0ERn6w13S3U8%3DBjV8-4EB4EUoAkw%40mail.gmail.com

Yoav Weiss

unread,

Nov 29, 2023, 10:24:48 AM11/29/23

to blink-dev, Christopher Cameron, Ken Russell

Thanks! This seems like an important problem to solve..

On Monday, November 27, 2023 at 10:20:37 PM UTC+1 Christopher Cameron wrote:

Contact emailsccam...@chromium.org

ExplainerNone

A short (inline?) explainer can help reviewers assess what this looks like and how developers may use it.

As is, it's not clear what the API surface for this is.

Specificationhttps://github.com/KhronosGroup/WebGL/pull/3222

What's preventing the PR from landing?

Summary
WebGL allows rendering into textures and renderbuffers of many different pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by default. This feature allows WebGL to configure the pixel format of this drawing buffer. This feature enables WebGL developers to: * avoiding an an extra copy convert their rendering to the default drawing buffer pixel format * draw content that has a more than 8 bits of precision The latter feature unlocks several additional applications * very wide color gamut content without loss of precision * medical applications which require >8 bits of precision * high dynamic range applications (when available)

Blink componentBlink>WebGL

TAG reviewNone

TAG review statusNot applicable

Availability expectationFeature is available on Web Platform in less than a year following launch in Chrome.

Adoption expectationSeveral specific partners have been using this feature being chrome://flags' "experimental web platform features", and intend to adopt this as soon as it is supported.

Estimated milestonesShipping on desktop122Shipping on Android122Shipping on WebView122

Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5146687245123584

Christopher Cameron

unread,

Dec 15, 2023, 4:49:02 AM12/15/23

to Yoav Weiss, blink-dev, Ken Russell

Thank you!

On Wed, Nov 29, 2023 at 4:24 PM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks! This seems like an important problem to solve..

On Monday, November 27, 2023 at 10:20:37 PM UTC+1 Christopher Cameron wrote:
Contact emailsccam...@chromium.org

ExplainerNone

A short (inline?) explainer can help reviewers assess what this looks like and how developers may use it.

As is, it's not clear what the API surface for this is.

Sure! This adds one new call to the WebGLRenderingContextBase interface (the base interface for WebGL and WebGL2). That call is

void drawingBufferStorage(GLenum sizedformat, GLsizei width, GLsizei height);

This allows the user to change the pixel format (along with the width and height) of the drawing buffer. This is similar to the existing renderbufferStorage function, which can be used to change these properties of an explicitly allocated offscreen buffer.

Specificationhttps://github.com/KhronosGroup/WebGL/pull/3222

What's preventing the PR from landing?

+Ken Russell to verify: My understanding is that the PR is to land after there exists an implementation shipping this.

Rick Byers

unread,

Dec 15, 2023, 11:58:31 AM12/15/23

to Christopher Cameron, Yoav Weiss, blink-dev, Ken Russell

On Fri, Dec 15, 2023 at 4:49 AM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:

Thank you!

On Wed, Nov 29, 2023 at 4:24 PM Yoav Weiss <yoav...@chromium.org> wrote:
Thanks! This seems like an important problem to solve..

On Monday, November 27, 2023 at 10:20:37 PM UTC+1 Christopher Cameron wrote:
Contact emailsccam...@chromium.org

ExplainerNone

A short (inline?) explainer can help reviewers assess what this looks like and how developers may use it.

As is, it's not clear what the API surface for this is.

Sure! This adds one new call to the WebGLRenderingContextBase interface (the base interface for WebGL and WebGL2). That call is

void drawingBufferStorage(GLenum sizedformat, GLsizei width, GLsizei height);

This allows the user to change the pixel format (along with the width and height) of the drawing buffer. This is similar to the existing renderbufferStorage function, which can be used to change these properties of an explicitly allocated offscreen buffer.

Specificationhttps://github.com/KhronosGroup/WebGL/pull/3222

What's preventing the PR from landing?

+Ken Russell to verify: My understanding is that the PR is to land after there exists an implementation shipping this.

Great! If an editor can confirm on the PR that it's blocked only on implementation support, then I'm happy approving this intent. Normally things go in the other order, but I don't actually care which happens first. We just want confirmation that the spec work has been completed to an appropriate quality level to enable future interoperability.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj9wHToypq6PpVYNajJET0m0RafiBwXPu%2BHG%2BRpQxbpZFw%40mail.gmail.com.

Vladimir Levin

unread,

Dec 15, 2023, 12:36:04 PM12/15/23

to Christopher Cameron, blink-dev, Ken Russell

On Mon, Nov 27, 2023 at 4:20 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:

Contact emails
ccam...@chromium.org

Explainer
None

Specification
https://github.com/KhronosGroup/WebGL/pull/3222

Summary
WebGL allows rendering into textures and renderbuffers of many different pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by default. This feature allows WebGL to configure the pixel format of this drawing buffer. This feature enables WebGL developers to: * avoiding an an extra copy convert their rendering to the default drawing buffer pixel format * draw content that has a more than 8 bits of precision The latter feature unlocks several additional applications * very wide color gamut content without loss of precision * medical applications which require >8 bits of precision * high dynamic range applications (when available)

Blink component
Blink>WebGL

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility
None.

Gecko: Positive Feature authored by Mozilla.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/278)

Web developers: Positive Positive feedback from several high profile web developers - 3D engines that use physically based rendering - image editing formats (especially for HDR) - medical imaging applications (which require >8 bit precision)

This feature sounds like a good addition to the platform. Are there any (public) links that you point to for developer feedback? I'm mostly curious to see the discussions

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj-0wf-RFAnEaKjT3kJPrMo78QCaEhQZ5EXua4sg2O9qKg%40mail.gmail.com.

Christopher Cameron

unread,

Dec 15, 2023, 1:02:09 PM12/15/23

to Vladimir Levin, blink-dev, Ken Russell

On Fri, Dec 15, 2023 at 6:35 PM Vladimir Levin <vmp...@google.com> wrote:

On Mon, Nov 27, 2023 at 4:20 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:
Contact emails
ccam...@chromium.org

Explainer
None

Specification
https://github.com/KhronosGroup/WebGL/pull/3222

Summary
WebGL allows rendering into textures and renderbuffers of many different pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by default. This feature allows WebGL to configure the pixel format of this drawing buffer. This feature enables WebGL developers to: * avoiding an an extra copy convert their rendering to the default drawing buffer pixel format * draw content that has a more than 8 bits of precision The latter feature unlocks several additional applications * very wide color gamut content without loss of precision * medical applications which require >8 bits of precision * high dynamic range applications (when available)

Blink component
Blink>WebGL

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility
None.

Gecko: Positive Feature authored by Mozilla.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/278)

Web developers: Positive Positive feedback from several high profile web developers - 3D engines that use physically based rendering - image editing formats (especially for HDR) - medical imaging applications (which require >8 bit precision)

This feature sounds like a good addition to the platform. Are there any (public) links that you point to for developer feedback? I'm mostly curious to see the discussions

There are a couple of external partners (I'll have to check before sharing them). Their feedback has been "when is this shipping?".

Ken Russell

unread,

Dec 15, 2023, 9:45:23 PM12/15/23

to Rick Byers, Christopher Cameron, Yoav Weiss, blink-dev

On Fri, Dec 15, 2023 at 8:58 AM Rick Byers <rby...@chromium.org> wrote:

On Fri, Dec 15, 2023 at 4:49 AM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:
Thank you!

On Wed, Nov 29, 2023 at 4:24 PM Yoav Weiss <yoav...@chromium.org> wrote:
Thanks! This seems like an important problem to solve..

On Monday, November 27, 2023 at 10:20:37 PM UTC+1 Christopher Cameron wrote:
Contact emailsccam...@chromium.org

ExplainerNone

A short (inline?) explainer can help reviewers assess what this looks like and how developers may use it.

As is, it's not clear what the API surface for this is.

Sure! This adds one new call to the WebGLRenderingContextBase interface (the base interface for WebGL and WebGL2). That call is

void drawingBufferStorage(GLenum sizedformat, GLsizei width, GLsizei height);

This allows the user to change the pixel format (along with the width and height) of the drawing buffer. This is similar to the existing renderbufferStorage function, which can be used to change these properties of an explicitly allocated offscreen buffer.

Specificationhttps://github.com/KhronosGroup/WebGL/pull/3222

What's preventing the PR from landing?

+Ken Russell to verify: My understanding is that the PR is to land after there exists an implementation shipping this.

Great! If an editor can confirm on the PR that it's blocked only on implementation support, then I'm happy approving this intent. Normally things go in the other order, but I don't actually care which happens first. We just want confirmation that the spec work has been completed to an appropriate quality level to enable future interoperability.

Actually I think the PR https://github.com/KhronosGroup/WebGL/pull/3222 has been a bit stalled. I'm not one of the WebGL spec editors but have emailed Khronos' internal mailing list asking the rest of the working group whether we can clean up / land that PR. It does seem to me that we should land the spec PR first, but Chris, feel free to ask on the PR as well.

Thanks,

-Ken

Chris Harrelson

unread,

Dec 20, 2023, 11:38:02 AM12/20/23

to Christopher Cameron, blink-dev, Ken Russell

On Mon, Nov 27, 2023 at 1:20 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:

Contact emails
ccam...@chromium.org

Explainer
None

Specification
https://github.com/KhronosGroup/WebGL/pull/3222

Summary
WebGL allows rendering into textures and renderbuffers of many different pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by default. This feature allows WebGL to configure the pixel format of this drawing buffer. This feature enables WebGL developers to: * avoiding an an extra copy convert their rendering to the default drawing buffer pixel format * draw content that has a more than 8 bits of precision The latter feature unlocks several additional applications * very wide color gamut content without loss of precision * medical applications which require >8 bits of precision * high dynamic range applications (when available)

Blink component
Blink>WebGL

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility
None.

Gecko: Positive Feature authored by Mozilla.

If they didn't tell you specifically that it's not necessary, please file one, thanks.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj-0wf-RFAnEaKjT3kJPrMo78QCaEhQZ5EXua4sg2O9qKg%40mail.gmail.com.

Ken Russell

unread,

Dec 20, 2023, 2:26:57 PM12/20/23

to Chris Harrelson, Christopher Cameron, blink-dev

On Wed, Dec 20, 2023 at 8:37 AM Chris Harrelson <chri...@chromium.org> wrote:

On Mon, Nov 27, 2023 at 1:20 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:
Contact emails
ccam...@chromium.org

Explainer
None

Specification
https://github.com/KhronosGroup/WebGL/pull/3222

Summary
WebGL allows rendering into textures and renderbuffers of many different pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by default. This feature allows WebGL to configure the pixel format of this drawing buffer. This feature enables WebGL developers to: * avoiding an an extra copy convert their rendering to the default drawing buffer pixel format * draw content that has a more than 8 bits of precision The latter feature unlocks several additional applications * very wide color gamut content without loss of precision * medical applications which require >8 bits of precision * high dynamic range applications (when available)

Blink component
Blink>WebGL

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility
None.

Gecko: Positive Feature authored by Mozilla.

If they didn't tell you specifically that it's not necessary, please file one, thanks.

FYI Mozilla's rep (and author of the drawingBufferStorage spec) gave a thumbs-up on Khronos' private WebGL working group mailing list. I'll work to get https://github.com/KhronosGroup/WebGL/pull/3222 landed; I think that should suffice as signal from Mozilla as well as other vendors.

-Ken

--

I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. (credit: jparent@)

Ken Russell

unread,

Dec 20, 2023, 2:27:32 PM12/20/23

to Chris Harrelson, Christopher Cameron, blink-dev

(Re-sending from correct email address)

On Wed, Dec 20, 2023 at 8:37 AM Chris Harrelson <chri...@chromium.org> wrote:

On Mon, Nov 27, 2023 at 1:20 PM 'Christopher Cameron' via blink-dev <blin...@chromium.org> wrote:
Contact emails
ccam...@chromium.org

Explainer
None

Specification
https://github.com/KhronosGroup/WebGL/pull/3222

Summary
WebGL allows rendering into textures and renderbuffers of many different pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by default. This feature allows WebGL to configure the pixel format of this drawing buffer. This feature enables WebGL developers to: * avoiding an an extra copy convert their rendering to the default drawing buffer pixel format * draw content that has a more than 8 bits of precision The latter feature unlocks several additional applications * very wide color gamut content without loss of precision * medical applications which require >8 bits of precision * high dynamic range applications (when available)

Blink component
Blink>WebGL

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility
None.

Gecko: Positive Feature authored by Mozilla.

If they didn't tell you specifically that it's not necessary, please file one, thanks.

FYI Mozilla's rep (and author of the drawingBufferStorage spec) gave a thumbs-up on Khronos' private WebGL working group mailing list. I'll work to get https://github.com/KhronosGroup/WebGL/pull/3222 landed; I think that should suffice as signal from Mozilla as well as other vendors.

-Ken

Ken Russell

unread,

Dec 20, 2023, 4:45:19 PM12/20/23

to Chris Harrelson, Christopher Cameron, blink-dev

The PR has been merged into the WebGL spec, viewable at https://registry.khronos.org/webgl/specs/latest/1.0/ . Are OWNERS here comfortable taking that as a positive signal from Mozilla/Apple?

Mike Taylor

unread,

Dec 20, 2023, 4:56:32 PM12/20/23

to Ken Russell, Chris Harrelson, Christopher Cameron, blink-dev

Given that Kelsey gave you a private positive signal and the spec is merged, that works for me.

LGTM1 to ship.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMYvS2dyA0p4zUykxus8u%3DoHV_4CcJEj4NqR4aGyBMZ7g2HPtw%40mail.gmail.com.

Chris Harrelson

unread,

Dec 20, 2023, 5:00:36 PM12/20/23

to Mike Taylor, Ken Russell, Christopher Cameron, blink-dev

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e7bd99c-154f-41dc-b427-b89f997d11cf%40chromium.org.

Alex Russell

unread,

Jan 3, 2024, 11:39:20 AMJan 3

to blink-dev, Chris Harrelson, Kenneth Russell, Christopher Cameron, blink-dev, Mike Taylor

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj-0wf-RFAnEaKjT3kJPrMo78QCaEhQZ5EXua4sg2O9qKg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMYvS2dyA0p4zUykxus8u%3DoHV_4CcJEj4NqR4aGyBMZ7g2HPtw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Reply all

Reply to author

Forward