Should supportedColorFormats and supportedDepthStencilFormats also return the type?

[Rik Cabanier]

The current spec returns a list of glenums that describe the color format of the swapchain (ie RGBA).
However, we are silent on what the pixel type of the swapchain is (ie UNSIGNED_SHORT_4_4_4_4).

Should we return list of pairs with the format + type instead?

[Rik Cabanier]

@toji should this also be done for WebGPU?

[Artem Bolgar]

We just use sized formats, like GL_RGBA8, GL_RGB8. But in terms of WebGL, these types are supported only by WebGL 2.
The type makes no sense for the compressed textures either.

[Rik Cabanier]

We need it so the author knows the type of the swapchain textures. Otherwise we would have to document what types are acceptable for each format.

[surffer3d]

So the function, as it is now, does not allow to fully use webgl capabilities. That would prevent, for instance, the creation of a 16 bits texture layer for webgl, if the EXT_texture_half_float and EXT_color_buffer_half_float were enabled. I don't know if that will be an issue or not, though.

By reading the documentation, I understand that the function returns valid formats meant to be used for textures, that will end up being attached to an FBO. So I guess only color/depth renderable formats would be allowed. If that is correct, then:

1. I think compressed formats are not supported as renderable.
2. How about return always sized values from the supported format list, even on webgl? Sized values are valid, for instance, when creating an attachment with a renderbuffer (renderable) rather than a texture, so they could make sense too. If the implementation uses textures and not renderbuffers, it will need to perform a translation from sizedFormat to unsizedFormat+type (ie. GL_RGBA16F --> GL_RGBA,GL_HALF_FLOAT), which can be easily done. The current documentation of supportedColorFormats says that it returns valid formats for XRCompositor, so it does not need to be the direct mapping of the glTexImage of OpenGL. An explanation on the documentation can be included, like the statements of the opaque textures, where there is a difference on webgl and webgl2.

Other 2 options I see for webgl are those:

1. Return the real texture internal formats (I.e GL_RGB, GL_RGBA) as of webgl specification, which are unsized. Then assume a predefined type for it, like 8 bits. Then it would not be possible to get a 16 bit buffer.
2. Add the second parameter for the function. If so, it would be optional for the webgl2 interface.

[Rik Cabanier]

...

1. I think compressed formats are not supported as renderable.

Swapchain textures are special. We already verified that you can render to a compressed swapchain.

2. How about return always sized values from the supported format list, even on webgl? Sized values are valid, for instance, when creating an attachment with a renderbuffer (renderable) rather than a texture, so they could make sense too. If the implementation uses textures and not renderbuffers, it will need to perform a translation from sizedFormat to unsizedFormat+type (ie. GL_RGBA16F --> GL_RGBA,GL_HALF_FLOAT), which can be easily done.

I think it will be very confusing for authors if they have to deal with WebGL2 formats while they use WebGL1.

...
Other 2 options I see for webgl are those:

1. Return the real texture internal formats (I.e GL_RGB, GL_RGBA) as of webgl specification, which are unsized. Then assume a predefined type for it, like 8 bits. Then it would not be possible to get a 16 bit buffer.

Yes, that would work for Oculus since we only do 8 bits for these types but I'd like to hear from other vendors if they support more.

2. Add the second parameter for the function. If so, it would be optional for the webgl2 interface.

Aren't some formats still reliant on the type?
For instance, the webgl2 spec states the following:

Internal Format	Format	Type
RGB	RGB	UNSIGNED_BYTE, UNSIGNED_SHORT_5_6_5
RGBA	RGBA	UNSIGNED_BYTE, UNSIGNED_SHORT_4_4_4_4, UNSIGNED_SHORT_5_5_5_1

[surffer3d]

I think it will be very confusing for authors if they have to deal with WebGL2 formats while they use WebGL1.
Yes, Ialso think so.

Aren't some formats still reliant on the type?
For instance, the webgl2 spec states the following:

Internal Format Format Type
RGB RGB UNSIGNED_BYTE, UNSIGNED_SHORT_5_6_5
RGBA RGBA UNSIGNED_BYTE, UNSIGNED_SHORT_4_4_4_4, UNSIGNED_SHORT_5_5_5_1

texImage2D accepts those formats on the spec. But if the texture is configured by using textureStorage2D, then just the sized formats are allowed.

[Rik Cabanier]

I agree this is all a bit confusing.
So, you can use texImage2D directly on a swapchain texture without making it a render target. This mean that you can directly write to these texture using texImage2D.

We should document this in the description of opaque textures.

[Rik Cabanier]

This method was removed so this issue is no longer relevant.