1719154 - webgl2 texSubImage2D performance issues

Status: RESOLVED DUPLICATE of bug 1883225

(Core :: Graphics: CanvasWebGL, defect, P2)

Description

[Alexander]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Calling texSubImage2d is ~10 times slower on Firefox than on Chrome.
See this fiddle: https://jsfiddle.net/gnfu7tyo/1/
Code is taken mostly from https://webglfundamentals.org/, so it's not exactly minimal, but a pretty standard set-up. Relevant part is line 164-180.
Here, a canvas is created and used to update a texture. All textures are power of 2.

Actual results:

On my machine, Chrome takes around ~500ms, Firefox needs 5s.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Sebastian Müller]

I can confirm what you are seeing. On my Intel HD 650 on Win10, Chrome/Edgium takes about 400ms for the test and Firefox takes more than 6s to finish.

Comment 3

[Alexander]

Any update on this? It's still tracked as 'unconfirmed', but it's pretty easy to verify by using the attached jsfiddle. I am making heavy use of this call through a texture atlas and this causes a huge disparity in loading times between browsers.

Comment 4

[dustin.kerstein]

Yeah, this is a major performance issue for many production sites. Here's probably a duplicate bug I just posted - https://bugzilla.mozilla.org/show_bug.cgi?id=1736923 - Any sites that use video in WebGL are absolutely destroyed by this bug - Check this pure WebGL video test - https://jsfiddle.net/Lmy0b3xt (this plays back at 60fps in latest Chrome and ~5fps on Firefox 93).

Comment 5

[Kelsey Gilbert [:jgilbert]]

This might be the RGB vs RGBA/X vs BGRA/X issue.

Comment 6

[Alexander]

(In reply to Kelsey Gilbert [:jgilbert] (previously Jeff) from comment #5)

This might be the RGB vs RGBA/X vs BGRA/X issue.

So what's the workaround? I trial&error'ed multiple formats to no avail. No matter what I set as type/internalFormat in https://jsfiddle.net/gnfu7tyo/1/ it is always Firefox ~5000ms, Chrome ~400ms.

Comment 7

[Wessel Kroos]

(In reply to Kelsey Gilbert [:jgilbert] from comment #5)

This might be the RGB vs RGBA/X vs BGRA/X issue.

This is not the RGB vs RGBA issue. The internalFormat RGBA (~125ms) is generally 2x faster than RGB (~250ms).
This issue is about the pipeline taking the slow path (~125ms) instead of the fast path (< 1ms) to read pixel data from the source image.
The fast path takes < 1ms while performance of the slow path depends on the amount of pixels in the source image.

Things I found out while debugging this performance problem in one of my web extensions:

1. When the source is a video or img element:

• texImage2D, texSubImage2D and createImageBitmap take the fast path (< 1ms)

2. When the source is a Bitmap or a canvas element (WebGLRenderingContext or CanvasRenderingContext2D):

• texImage2D, texSubImage2D, createImageBitmap and transferToImageBitmap takes the slow path (125ms)

3. The decision to take the slow or fast path seems to depend on the source element.
4. The difference between the slow and fast path:

• This slow path always goes through the internal function gl::Framebuffer::readPixels which reads the pixel data from the source image and writes it to the CPU memory.
• The fast path keeps the pixel data of the source image in the GPU memory.

5. This performance issue is present in all these functions:

• WebGLRenderingContext.texImage2D
• WebGLRenderingContext.texSubImage2D
• createImageBitmap
• HtmlCanvasElement.transferToImageBitmap

Comment 8

[n3tfr34k]

Im also affected from this issue. Calling variants of drawImage should always reuse texture data in GPU memory like in Google Chrome, where is no real lag (< 1ms), and not recopy it over CPU+RAM.

@Wessel Kroos made a good summary for this.

I don't find any workaround for this. Tried WebGL Variants, Canvas 2D, bitmaprenderer, creating VideoFrame's. Everything is really slow for realtime use-cases with large resolutions. Also the memory usage (grow) is insane with this.

Hope this issue gets more attention in the future.

Comment 9

[Wessel Kroos]

texImage2D performance from a video element seems to be improved in Firefox 123. The duration has been decreased from 31ms to 2ms while running @dustin.kerstein 's example https://jsfiddle.net/dustinkerstein/Lmy0b3xt/

However:

• This improvement has also introduced a performance regression 1883225
• And example https://jsfiddle.net/gnfu7tyo/1/ has not improved