Open fserb opened 2 years ago
Some quick questions. I assume all of this has been discussed before, so apologies in advance.
getCurrentTexture()
is the right thing.GPUCanvasAlphaMode
only support opaque
and premultiplied
and not transparent
(i.e., non-premul alpha)?transferToImageBitmap()
returns a copy AND replaces the drawing buffer? Shouldn't it be one or the other? I'm assuming the other read operations (drawImage, texImage2D, etc) that return a copy don't destroy the current drawing buffer, right? unconfigure()
?configure()
, Is there potential for any part of validation to be an expensive operation? I.e., that the UA has to actually try to to render a texture for the current GPUDevice
(as opposed to just checking that a format is part of a set or that a parameter is technically supported)?getCurrentTexture()
only checks if the texture is null. Is there any place that where a destroyed texture is nullified, so a new one is created by genCurrentTexture()
?
- Resizing mechanism lgtm. I think failing on
getCurrentTexture()
is the right thing.
FWIW configure()
can also fail based on canvas size at the time of configure. This happens because the entire GPUTextureDescriptor
gets validated out of simplicity, but isn't strictly necessary.
- Any reason why
GPUCanvasAlphaMode
only supportopaque
andpremultiplied
and nottransparent
(i.e., non-premul alpha)?
Experience with WebGL has shown that compositing unpremultiplied transparent images is quite costly on many systems due to the lack of OS primitives to do so. https://github.com/gpuweb/gpuweb/issues/1425#issuecomment-777165832, https://github.com/gpuweb/gpuweb/issues/1425#issuecomment-778579560, https://github.com/gpuweb/gpuweb/issues/1425#issuecomment-784535111
- Maybe I missed something, but why
transferToImageBitmap()
returns a copy AND replaces the drawing buffer? Shouldn't it be one or the other? I'm assuming the other read operations (drawImage, texImage2D, etc) that return a copy don't destroy the current drawing buffer, right?
It's described as a copy+replace because it was easier to specify because of the interaction of the underlying image contents with other stuff in the spec. There is a non-normative note that says an actual copy isn't necessary.
- What is the use case for
unconfigure()
?
It returns the context back to its initial state where it is not attached to any GPUDevice and doesn't have any image data. The envisioned use-case is that it lets you free up the canvas-device interop. It is probably not strictly necessary. https://github.com/gpuweb/gpuweb/issues/1822#issuecomment-861014718
- On
configure()
, Is there potential for any part of validation to be an expensive operation? I.e., that the UA has to actually try to to render a texture for the currentGPUDevice
(as opposed to just checking that a format is part of a set or that a parameter is technically supported)?
In general there shouldn't be, though the logic for allocating canvas textures in a browser could be arbitrarily complex. The spec doesn't technically allow configure() or getCurrentTexture() to fail for any reason other than straightforward validation (format is one of a specific set, format can be used with specified texture usage, etc.) This is the same validation that occurs in createTexture. Also note that even if there are complex things going on behind the scenes, they should at least theoretically not need to be blocking.
- I tried the follow the rendering update flow, and it seems that it destroys the current texture, but then
getCurrentTexture()
only checks if the texture is null. Is there any place that where a destroyed texture is nullified, so a new one is created bygenCurrentTexture()
?
It is only set to null
in Replace the drawing buffer. I think you did indeed find a bug here.
cc @junov as well
Creating this topic for @whatwg/canvas to discuss WebGPU integration as stated here.