2081675 - Drawing software-decoded 4K VideoFrames with WebGL halves the page frame rate (60 → 30 fps) on Linux

Status: NEW

(Core :: Audio/Video: Web Codecs, defect)

Description

[nicfio]

Attachment: Testcase: testcase.html + 3840x2160 H.264 sample (60 frames)

Steps to reproduce:

1. Unzip testcase.zip, run python3 -m http.server in that folder.
2. Open http://localhost:8000/testcase.html and wait about 15 seconds.
3. Open http://localhost:8000/testcase.html?acc=prefer-hardware and wait again.

The page feeds a 3840×2160 H.264 clip to a VideoDecoder in real time (one chunk every 1/60 s, optimizeForLatency: true), and on each requestAnimationFrame draws the newest frame with WebGL2 texImage2D. Then it times createImageBitmap(frame) and canvas 2D drawImage(frame) on 30 frames.

Actual results (Firefox 158.0; the same in 153.4.0esr and Nightly 160.0a1):

• prefer-software: all 600 frames are decoded on time, but requestAnimationFrame runs every 32 ms and only about 370 of 600 frames are drawn.
• prefer-hardware: requestAnimationFrame every 16 ms, about 565 of 600 frames drawn.
• createImageBitmap(frame): median 14 ms (hardware frames), 9 ms (software frames).

Expected results, Chrome 154 on the same machine:

• requestAnimationFrame every 16.7 ms in both modes (530 and 558 of 600 frames drawn).
• createImageBitmap(frame): 0.4 ms (hardware), 2.6 ms (software).

Notes:

• Decoding is not the bottleneck. Decode latency (chunk in → frame out) has a median of 5–6 ms at 4K, and software decoding at full speed reaches about 800 fps at 4K (Chrome about 380).
• The page runs on hardware WebRender (about:support: Compositing WebRender, attached). With gfx.webrender.all=true the results are the same. With gfx.webrender.software=true the prefer-hardware case also drops to 30 fps.
• At 1080p the drop does not happen; createImageBitmap is 3–4 ms (Chrome 0.2 ms).
• createImageBitmap(frame) on 4K frames takes 14 ms in 158 and 18 ms in Nightly 160.0a1 (build 20261013), against 0.4 ms in Chrome. That Nightly should include bug 2070629. The canvas 2D drawImage numbers in the testcase are not reliable: the page calls getImageData(0, 0, 1, 1) to wait for the draw, which forces a readback.
• A larger set of measurements is attached (3 runs × 4 browsers; 1080p and 4K; software and hardware; latency, throughput, CPU use). Firefox Profiler profiles of the 4K cases (no about:logging presets):
  • 153.4.0esr (Debian build): https://profiler.firefox.com/public/0e9w974ftknb4r9bt16pk8hbh5739ys7v90rdbg
  • 158.0: https://profiler.firefox.com/public/nh7t4ye3024zv6km4v8hfhmwv9wfsh33bbb10zg
  • 160.0a1: https://profiler.firefox.com/public/9b0jy48dsrk1grshbksgv7xev64svm93fqaczz0

System: Debian 13 (trixie), kernel 7.0, Intel Core i5-13500T, 32 GB RAM, AMD Radeon RX 6800 (Mesa 25.0.7, radeonsi, VA-API). Wayland: labwc 0.8.3 with its headless backend, rendering on the RX 6800, 1280×720 at 60 Hz.

Possibly related: bug 1926801, bug 1926791, bug 1963199, bug 2070629.

Comment 1

[nicfio]

Attachment: about:support, Firefox 158.0 (same machine and setup as the measurements)

Comment 2

[nicfio]

Attachment: Full measurements: ESR 153.4, 158.0, Nightly 160.0a1, Chrome 154 (3 runs each, 1080p and 4K, software and hardware)

Comment 3

[Paul Adenot (:padenot)]

Yeah well we're spending 35% of the thread doing memset [0] on the canvas thread, and at that size, this likely destroys caches and bandwidth and all that.

https://profiler.firefox.com/public/0e9w974ftknb4r9bt16pk8hbh5739ys7v90rdbg/calltree/?globalTrackOrder=0615243&hiddenGlobalTracks=1w5&hiddenLocalTracksByPid=911296-3w79wg~911439-0~911606-0~911600-0~911593-0~911614-0w3~911467-3&thread=3&v=17

Comment 4

[Paul Adenot (:padenot)]

https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=104846 with a possible patch, but I think we can do better by using a better texture format prior to uploading. My Linux workstation is being repaired so I haven't tested that that much.

Comment 5

[nicfio]

Thanks for looking into this so quickly!

Since your Linux workstation is out for repair, I'm happy to help get this fixed: I can test your try build (and any later patch, e.g. the texture-format approach) on the same Linux machine and with the same test page used for this report, and post before/after numbers and new profiles here.

Just let me know which build to use, or I'll take the artifacts from the try push above once it's finished.