Define WebGPU canvas read behavior#1839
Conversation
6b23e42 to
9014d39
Compare
c042588 to
f8dc62d
Compare
|
Tweaked verbiage looks good, thanks! |
|
I thought worth mentioning that in the html spec TransferToImageBitmap is reference more as "moving out the original content" and then leaving one new in place, rather than how it will be mentioned in the WebGPU spec of copying out the internal content and reseting the internal one. Nevertheless, the outcome and expectations are the same, so I think it's good as it is written! lgtm, thanks adding this! |
spec/index.bs
Outdated
| Note: | ||
| When the *user* initiates a read of a WebGPU canvas, e.g. using "Copy to Clipboard", | ||
| "Save Image As...", printing, etc., the user agent **should** return the contents displayed on the | ||
| screen at that moment, if possible (not the contents of {{GPUPresentationContext/[[currentTexture]]}}. |
There was a problem hiding this comment.
Want to make sure this matches the behavior of other canvas types. I don't think webgl or 2d canvas have a way to export the previously displayed frame since that's been handed over to the display compositor. One way of meeting this requirement is triggering a compositing update when any of these actions are initiated so that the contents on screen matches the content copied/saved.
There was a problem hiding this comment.
I did some quick investigation and it looks like all of these actions actually cannot happen during a JS task anyway - I think they occur as events on the event loop which means they can just trigger "update the rendering [of the] Document" to get the contents. At least in the case of printing, I think they must trigger it, because printing requires page relayout; I think copying probably triggers it as well.
Anyway, based on that, I don't think there's any danger of implementations returning [[currentTexture]]'s contents in the middle of a frame, so I'm just going to remove this note.
f8dc62d to
29e806a
Compare
Fixes #1781
Preview | Diff