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 support opaque and premultiplied and not transparent (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. gpuweb/gpuweb#1425 (comment), gpuweb/gpuweb#1425 (comment), gpuweb/gpuweb#1425 (comment)

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.
gpuweb/gpuweb#1822 (comment)

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 current GPUDevice (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 by genCurrentTexture()?

It is only set to null in Replace the drawing buffer. I think you did indeed find a bug here.

Discuss WebGPU integration issues #8123

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions