gl.texImage2D<\/code> function accepts two types of sources, a TypedArray<\/code> or a DOM pixel source. The latter includes any of these objects:<\/p>\n\n\n\n\nImageBitmap<\/code><\/a><\/li>\n\n\n\nImageData<\/code><\/a><\/li>\n\n\n\nHTMLImageElement<\/code><\/a><\/li>\n\n\n\nHTMLCanvasElement<\/code><\/a><\/li>\n\n\n\nHTMLVideoElement<\/code><\/a><\/li>\n\n\n\nOffscreenCanvas<\/code><\/a><\/li>\n\n\n\nVideoFrame<\/code><\/a><\/li>\n<\/ul>\n\n\n\nSimilarly, in WebGPU we can populate GPUTexture<\/code> objects using queue.copyExternalImageToTexture<\/code> which accepts the same DOM pixel sources.<\/p>\n\n\n\nWith all these options, it’s up to the developer to choose what pathway to use. Sometimes the image data is already in a particular form and the choice is made for you. But most of the time you’re fetching an image from a URL, and the question becomes: which API gets the pixels onto the GPU fastest?<\/p>\n\n\n\n
As we will see, WebGPU is still a young API with immature implementations, and depending on the pathway you pick, you can also run into color space bugs or formats that simply don’t work.<\/p>\n\n\n\n
createImageBitmap<\/code><\/h2>\n\n\n\nThe createImageBitmap<\/code><\/a> method returns a promise that resolves to an ImageBitmap<\/code><\/a> and, in theory, it provides an asynchronous and resource-efficient pathway to prepare textures for rendering in WebGPU and WebGL that is widely supported across browsers.<\/p>\n\n\n\nLike the WebGL and WebGPU APIs, it accepts a variety of image sources, but the most useful input is a Blob<\/code><\/a>. This gives us a clean separation between fetching the image and decoding it:<\/p>\n\n\n\nexport async function loadImageBitmap(url) {\n const res = await fetch(url, { mode: \"cors\" })\n if (!res.ok) throw new Error(`HTTP ${res.status} for ${url}`)\n const blob = await res.blob()\n\n return createImageBitmap(blob, {\n imageOrientation: \"none\",\n colorSpaceConversion: \"none\",\n premultiplyAlpha: \"none\"\n })\n}<\/code><\/pre>\n\n\n\nAdditionally it provides fine grained control over the image orientation, color space conversion and alpha format, which are features missing from the other pathways.<\/p>\n\n\n\n
Unfortunately, there are some issues:<\/p>\n\n\n\n
\n- SVG support is inconsistent.<\/strong> While the API promises support for SVG, the quality of the resulting images depends on the browser. Firefox produces the expected output, but in Safari and Chrome the resulting images are not antialiased. Additionally, if you provide an SVG file inside a blob (instead of an
SVGImageElement<\/code><\/a>) Chrome does not produce valid output.<\/li>\n\n\n\n- Color space conversion bugs.<\/strong> Safari has known issues when passing
ImageBitmap<\/code> to copyExternalImageToTexture<\/code> (bug 296208<\/a>, and 295729<\/a>). These issues are fixed in Tahoe\/iOS 26, but given the low adoption rate of this release they are worth keeping in mind.<\/li>\n\n\n\n- Asynchronous does not mean concurrent.<\/strong> The asynchronous nature of the API allows browser implementations to offload the decoding to a separate thread, but in practice the only browser that seems to do this is Chrome. In Firefox decoding is serial (bug 1778394<\/a>) and Safari is slow, although I haven’t pinned down why.<\/li>\n<\/ul>\n\n\n\n
Even though on paper createImageBitmap<\/code> is the right API, in practice we have to look at the other alternatives to find more efficient solutions or work around deficiencies in the implementations.<\/p>\n\n\n\nSummary:<\/strong><\/p>\n\n\n\n\n- Chrome: Poor SVG support.<\/li>\n\n\n\n
- Safari: Poor SVG support. Color space conversion bugs.<\/li>\n\n\n\n
- Firefox: Correct, but synchronous. Decoding in the main thread.<\/li>\n<\/ul>\n\n\n\n
HTMLImageElement<\/code><\/h2>\n\n\n\nThe HTMLImageElement<\/code> interface represents an HTML <img><\/code><\/a> element, which we can hand over to the WebGL and WebGPU APIs directly. To create an image element asynchronously we can wrap it in a promise that is fulfilled when the image finishes loading:<\/p>\n\n\n\nexport function loadImageElement(url) {\n return new Promise((resolve, reject) => {\n const img = new Image()\n img.crossOrigin = \"anonymous\"\n img.decoding = \"async\" \/\/ hint to decode off the main thread when possible\n img.onload = () => resolve(img) \/\/ returns HTMLImageElement\n img.onerror = reject\n img.src = url\n })\n}<\/code><\/pre>\n\n\n\nThe decoding<\/code> attribute is an optional string representing a hint given to the browser on how to decode the image. async<\/code> means to decode it asynchronously. In practice the hint doesn’t seem to make much of a difference. Firefox still decodes synchronously in the main thread, and Safari appears only slightly faster.<\/p>\n\n\n\nOne of the drawbacks of this API is that there’s no way to specify the intended color space conversion or alpha format. This is a problem when loading images that are not intended for display, for example, normal maps or other texture data stored in linear space. In those cases Chrome seems to apply an sRGB transform, and produces washed-out colors, while Safari and Firefox leave the data as is. It’s unclear which behavior is correct, but for texture loading, Chrome’s transform makes this method unusable.<\/p>\n\n\n\n
This code path also supports loading SVG files, and in most cases the quality of the results is much better. However, prior to Safari 26, loading of image elements referencing SVG files was broken. A workaround is to render the SVG to a canvas which both WebGL and WebGPU accept as an input:<\/p>\n\n\n\n
async function convertImageElementToCanvas(img) {\n const canvas = document.createElement(\"canvas\")\n canvas.width = img.naturalWidth || img.width\n canvas.height = img.naturalHeight || img.height\n const ctx = canvas.getContext(\"2d\")\n ctx.drawImage(img, 0, 0)\n return canvas\n}<\/code><\/pre>\n\n\n\nWith this fix, loading of SVG files through the HTMLImageElement<\/code> code path produces correct results in all cases.<\/p>\n\n\n\nSummary:<\/strong><\/p>\n\n\n\n\n- Chrome: Inconsistent color space conversion.<\/li>\n\n\n\n
- Safari: Fastest option. Issue with SVG.<\/li>\n\n\n\n
- Firefox: Still synchronous.<\/li>\n<\/ul>\n\n\n\n
ImageDecoder<\/code><\/h2>\n\n\n\nA third alternative is to use the new WebCodecs API. Adoption of this API has been limited, because it’s only available in Chrome and Firefox. I was excited to try it out, because I had heard rumors about it being hardware accelerated. Probably not true, but the rumor itself suggested it might at least be faster than the alternatives.<\/p>\n\n\n\n
The code to use the ImageDecoder<\/code> API is fairly simple:<\/p>\n\n\n\nconst decoder = new ImageDecoder({\n data: blob.stream(),\n type: blob.type,\n colorSpaceConversion: \"none\",\n preferAnimation: false\n})\n\ntry {\n \/\/ Returns a VideoFrame; caller is responsible for calling .close() on it.\n const { image } = await decoder.decode()\n return image\n} finally {\n decoder.close()\n}<\/code><\/pre>\n\n\n\ndecoder.decode()<\/code> returns a promise to an object with an image attribute containing a VideoFrame<\/code> and we can create a texture from this VideoFrame<\/code> directly. Like createImageBitmap<\/code>, this code path supports specifying the desired color space conversion, but unlike it, there’s no way to specify the expected alpha format.<\/p>\n\n\n\nThere’s another caveat, in Firefox copyExternalImageToTexture<\/code> does not support VideoFrame<\/code>. This is a known issue that has already been reported at: bug 1975308<\/a>, but the workaround is fairly simple. We just wrap the VideoFrame<\/code> object in an ImageBitmap<\/code>. This is something that spark.encodeTexture<\/code> already handles in order to support arbitrary video sources:<\/p>\n\n\n\nif (getFirefoxVersion() && isVideoFrame) {\n const bitmap = await createImageBitmap(source)\n try {\n return await this.encodeTexture(bitmap, options)\n } finally {\n bitmap.close()\n }\n}<\/code><\/pre>\n\n\n\nTo benchmark this I used the glTF Sponza scene<\/a> I tested on a previous blog post<\/a>. <\/p>\n\n\n\n![\"\"](\"https:\/\/www.ludicon.com\/castano\/blog\/wp-content\/uploads\/2026\/05\/image-700x368.png\")
<\/figure>\n<\/div>\n\n\nHere are the results:<\/p>\n\n\n\nBrowser<\/th> createImageBitmap<\/code><\/th>ImageDecoder.decode<\/code><\/th><\/tr><\/thead>Chrome<\/td> 177 ms<\/td> 163 ms<\/td><\/tr> Firefox<\/td> 460 ms<\/td> 196 ms<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThe improvements in Chrome are modest, but on Firefox the difference is dramatic, suggesting the texture decoding finally happens off the main thread. Here’s a flame graph of the version of the code using createImageBitmap<\/code>, note how most of the time is spent in image decoding (in green):<\/p>\n\n\n\n![\"\"](\"https:\/\/www.ludicon.com\/castano\/blog\/wp-content\/uploads\/2026\/05\/image-1-700x178.png\")
<\/figure>\n<\/div>\n\n\nWith ImageDecoder<\/code>, the decoding time is gone entirely, and most of the time is spent on WebGPU’s copyExternalImageToTexture<\/code> (in blue):<\/p>\n\n\n\n![\"\"](\"https:\/\/www.ludicon.com\/castano\/blog\/wp-content\/uploads\/2026\/05\/image-2-700x270.png\")
<\/figure>\n<\/div>\n\n\nHowever, while the overall time is reduced, we are now spending a significant amount of time copying data, and in particular, doing pixel format conversions. Turns out that the VideoFrame<\/code> internal format is BGRA8 and our WebGPU texture is RGBA8.<\/p>\n\n\n\nI spent some time looking at that code to understand what I could do about that.<\/p>\n\n\n\n
The ConvertImage<\/code> function has a fast path for no-pixel format conversion that just performs memory copies, and a slow path that uses a generic WebGLImageConverter<\/code>. Firefox actually has some optimized pixel swizzling functions that have SSE2 and NEON implementations (gfx::SwizzleData<\/code> and gfx::SwizzleYFlipData<\/code>). I tried hooking them up and produced a noticeable improvement, but a better approach is to avoid the pixel conversion entirely.<\/p>\n\n\n\nChanging the pixel format used by Firefox internally would be tricky. There’s a lot of code that expects that particular format. Instead it’s much easier to change the format of our destination texture. We only use this intermediate texture as a staging texture prior to block compression and it doesn’t matter whether it uses RGBA8 or BGRA8. Allocating a BGRA8 texture puts us in the optimized memory copy path.<\/p>\n\n\n\n
The resulting timings are even better (note, I did not measure this change in Chrome):<\/p>\n\n\n\nBrowser<\/th> createImageBitmap<\/code><\/th>ImageDecoder<\/code> -> RGBA<\/th>ImageDecoder<\/code> -> BGRA<\/th><\/tr><\/thead>Firefox<\/td> 460 ms<\/td> 142 ms<\/td> 116 ms<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThis is a nice improvement, but I’m still not satisfied with this outcome. The remaining copy is necessary in Firefox, because WebGPU runs in a different process and in order to transfer the texture we have to place it in shared memory that is specifically allocated for this purpose. In an ideal world we would have the decoder thread output its result directly into shared memory, so that the main thread only has to hand it over to the GPU process without touching it.<\/p>\n\n\n\n
Another problem that still remains is that textures with alpha still go through a pixel format conversion. Turns out that the alpha channel in VideoFrame<\/code> objects is always premultiplied. On the other hand copyExternalImageToTexture<\/code> expects unpremultiplied alpha by default, so the pixel format converter has to divide the RGB by the alpha.<\/p>\n\n\n\nUnfortunately, there appears to be no way to specify that the alpha in the VideoFrame<\/code> is not to be premultiplied. We can eliminate the un-premultiplication, by requesting premultiplied data in copyExternalImageToTexture<\/code>, but that’s not what most applications want; often the alpha in game textures is used to encode data that’s not opacity.<\/p>\n\n\n\nThis is worrying not just because of the minor overhead, but because of potential quality issues. Premultiplication followed by unpremultiplication is a lossy transformation, it completely destroys RGB data in areas that are fully transparent, and when the alpha is close to zero the reconstruction is inaccurate and often leads to fireflies. You can see an example on the texture below:<\/p>\n\n\n
\n![\"\"](\"https:\/\/www.ludicon.com\/castano\/blog\/wp-content\/uploads\/2026\/05\/image-3-700x343.png\")
<\/figure>\n<\/div>\n\n\nThe RGBA codecs in spark.js assume that alpha is used for opacity and handle input like this gracefully, but this is still an issue if you intend to use the alpha channel for other purposes and don’t want it to interfere with the color.<\/p>\n\n\n\n
Finally, another issue is that support for the BGRA8 format is intentionally limited in WebGPU. It does not support STORAGE_BINDING<\/code> unless the \"bgra8unorm-storage\"<\/code> feature is supported and enabled, and even then, this only enables write-only access. That puts some serious restrictions in how we can use these textures.<\/p>\n\n\n\nFor example, we cannot use our compute mipmap generation without adding an extra blit. Currently Firefox does not support the compute-based mipmap generation because support for views with different pixel formats is also broken, but once that’s fixed this will add some overhead and additional complexity to that code path.<\/p>\n\n\n\n
Summary:<\/strong><\/p>\n\n\n\n\n- Chrome: Minor improvement. Possible alpha quality degradation.<\/li>\n\n\n\n
- Safari: Not available.<\/li>\n\n\n\n
- Firefox: Asynchronous and concurrent. Still some copy overhead. Alpha quality degradation.<\/li>\n<\/ul>\n\n\n\n
Conclusions<\/h2>\n\n\n\n
I spent quite a bit of time looking at performance in Firefox because it’s my browser of choice and also because I feel it has much fewer engineering resources than Chrome or Safari. That said, some of the issues I identified probably apply to the other browsers; I suspect the BGRA staging texture trick is worth trying regardless of your target.<\/p>\n\n\n\n
Summary:<\/strong><\/p>\n\n\n\n\n- For raster images:\n
\n- Chrome:
createImageBitmap<\/code> works as advertised, concurrent decoding, correct color handling.<\/li>\n\n\n\n- Safari: use
HTMLImageElement<\/code>. It’s faster than createImageBitmap<\/code> and avoids bugs in pre-Tahoe versions.<\/li>\n\n\n\n- Firefox: use
ImageDecoder<\/code>. It’s the only API on Firefox that decodes off the main thread.<\/li>\n<\/ul>\n<\/li>\n\n\n\n- For vector images: use
HTMLImageElement<\/code> or render to canvas in Safari prior to version 26.<\/li>\n<\/ul>\n\n\n\n