dictionary GPUImageBitmapCopyView {
required ImageBitmap imageBitmap;
GPUOrigin2D origin;
};
partial interface GPUQueue {
void copyImageBitmapToTexture(
GPUImageBitmapCopyView source,
GPUTextureCopyView destination,
// For now, copySize.z must be 1.
GPUExtent3D copySize);
};copyImageBitmapToTexture submits a copy from a source sub-rectangle of an ImageBitmap into a destination sub-resource of a GPUTexture.
The ImageBitmap must not be detached, if it is, a validation error is generated.
- Creating a
GPUTexturedirectly from anImageBitmap, attempting to avoid copies, is impractical because it requires the GPUTexture's format to match the internal representation of theImageBitmap, which is not exposed to the Web platform. Additionally,ImageBitmaps may be GPU- or CPU-backed, and wrapping a CPU-backedImageBitmapis a significant meta-operation that requires an additional copy to be submitted. - Having
copyImageBitmapToTextureonGPUCommandEncoder: this makes implementations much more complicated because they can't know when the copy will be effectively submitted. It also allows having multiplecopyImageBitmapToTextureat different sports in theGPUCommandEncoderwhich would require splicing the encoder and keeping track of all the chunks. Realistically, copyingImageBitmaps will be during loading to copy from<img>elements, or at most a couple times per frame for example to copy a camera frame, so an immediate copy is fine.
-
Some of the
ImageBitmapcreation options, such as"flipY", have semantics that have to match the target graphics API where the data is intended to be used. For WebGL,imageOrientation: "flipY"is necessary to ensure that the resultingWebGLTextureis oriented correctly. For WebGPU, it may be the case that texture origins are defined differently from WebGL, necessitatingimageOrientation: "none". These cases will have to be thoroughly tested. -
The browser may choose an internal representation for an
ImageBitmapwhich is not ideal for usage by WebGPU (or, for that matter, by WebGL). This could result in texture uploads being significantly more expensive than necessary due to per-pixel data swizzling during upload. Providing any hint about the intended usage of theImageBitmapduring its construction (for example "for use with WebGL" or "for use with this WebGPU adapter") would require changes to the HTML specification. Attempts to change Chrome's internal representation ofImageBitmaphave not yet been successful; it's not clear how feasible it would be in other browsers.