1938053 - lightningchart.com - FPS real-monitoring is lower compared to Chrome

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 133.0

Steps to reproduce:

1. Navigate to: https://lightningchart.com/js-charts/interactive-examples/examples/lcjs-example-0028-multiChannelLineProgressiveOwnAxes.html?disable-animations=1&isList=true
2. Observe the FPS visualization

Expected Behavior:
FPS is the same as in Chrome

Actual Behavior:
FPS is lower compared to Chrome

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/145313

Comment 1

[Raul Bucata]

Attachment: ff vs chrome

Comment 2

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

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

This bug was moved into the Performance component.

:rbucata, could you make sure the following information is on this bug?

• For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 4

[Raul Bucata]

I'm not sure what relevant information to attach in this case. I'll remove the needs info label, but feel free to ping me if a specific attachment is needed.

Comment 5

[Bas Schouten (:bas.schouten)]

Profile: https://share.firefox.dev/4gJGwec

This is dominated by canvas readback stuff and software.

The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Windows
Impact on site: Causes noticeable jank
Websites affected: Rare
[x] Able to reproduce locally

Comment 6

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

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Niilo Keinänen]

Hello,

I am reaching out to kindly request a priority assignment for this WebGL rendering bug. It's been affecting our product, LightningChart JS, for over three months now, and it's starting to hurt:

• Our users are seeing much slower WebGL performance in Firefox compared to other browsers
• We're getting more support tickets about this Firefox-specific issue
• Some customers are considering alternatives, which is impacting our business

We think this might warrant a P2 (or even P1) priority because:

1. It's a regression in core WebGL functionality
2. It affects many sites using our tech
3. It puts Firefox at a disadvantage compared to other browsers

We are happy to provide any other info you need in addition to the existing profiling data. We're also available to help test fixes.

Could someone from the graphics team please take a look and set an appropriate priority? Thanks so much for your time and effort!

Comment 8

[Kelsey Gilbert [:jgilbert]]

Bas is correct in Comment 5: https://share.firefox.dev/4iiSH2w
This is slowing down due to canvas2d.drawImage(webgl).

Comment 9

[Kelsey Gilbert [:jgilbert]]

Lee is the best person to speak for the status of drawImage-from-webgl optimization today.

Comment 10

[Lee Salzman [:lsalzman]]

I don't think this is a regression so much as something we've never really done well, and this requires new infrastructure to do well. The biggest hurdle is the ping-ponging from the GPU process to content process and back to GPU process to transit between WebGL and Canvas2D. Remote/Accelerated Canvas2D will accentuate this, but the bottleneck has always been there.

Comment 11

[Niilo Keinänen]

Thanks so much for your attention here everyone.
I'm also familiar that there is some historical performance bottleneck in Mozilla canvas2D drawImage. In our product this has been visible in use case where you have several charts in the same page. When comparing to other browsers, it has always performed clearly slower.

But I don't think the problem was as apparent before as discussed here, or perhaps better described in the original bug report https://github.com/webcompat/web-bugs/issues/145313

After some fairly recent Mozilla Firefox version update (no more than 2 weeks I'd say?) performance on the page has plummeted. Before FPS was easily 60. This is still the case on Chrome/Edge. Now its around ~10.

In this example case, it is after all just a single chart on the page. Confirming whether the performance here has degraded recently would be incredibly valuable. Is that something I can help with? (I don't think normal user interface allows selecting Mozilla version at least)

Comment 12

[Brian Albaugh]

Hello all. I ran the mozregression as suggested by padenot in the gfx chart for this issue.

The first fps regression was noticed here:

2025-03-21T11:41:54.241000: DEBUG : Found commit message:
Bug 1910138 - Disable Direct2D in Nightly. r=jrmuizel,aosmond

This disables the legacy Direct2D backend in Windows Nightly in favor
of using Accelerated Canvas2D instead. The goal of this experiment
is to collect performance and other bug feedback on AC2D versus Direct2D.

In general, AC2D has been fairly stable on other platforms, so it would be
nice to gradually move towards using AC2D on Windows as well so that we
are using one consistent acceleration solution.

This experiment is the first step towards that end.

Differential Revision: https://phabricator.services.mozilla.com/D217851

2025-03-21T11:41:54.241000: DEBUG : Did not find a branch, checking all integration branches
2025-03-21T11:41:54.243000: INFO : The bisection is done.
2025-03-21T11:41:54.244000: INFO : Stopped

---

The second, even more notable regression was noticed here:

2025-03-21T14:41:32.886000: DEBUG : Found commit message:
Bug 1914707 - Disable attrib divisor for non-array attribs. r=gfx-reviewers,lsalzman,bradwerth

Differential Revision: https://phabricator.services.mozilla.com/D222889

2025-03-21T14:41:32.886000: DEBUG : Did not find a branch, checking all integration branches
2025-03-21T14:41:32.887000: INFO : The bisection is done.
2025-03-21T14:41:32.888000: INFO : Stopped

---

NOTE: The fps drop is most noticeable when the browser window is in full screen mode.

Comment 13

[Brian Albaugh]

Also of not, the second more noticeable regression not only has reduced fps but also results in other graphically visual rendering issues.

Comment 16

[Lee Salzman [:lsalzman]]

Attachment: Bug 1938053 - Allow WebGLContext to generate backbuffer snapshots within GPU process. r?aosmond

CanvasTranslator needs to generate backbuffer snapshots for usage within the GPU process,
and thus it can't use the normal ClientWebGLContext interfaces for generating such.

This adds the necessary hook inside WebGLContext to do so.

Comment 17

[Lee Salzman [:lsalzman]]

Attachment: Bug 1938053 - Accelerate canvas drawImage of a WebGL context. r?aosmond

Accelerated Canvas2D and WebGL both live within the GPU process and run within
the same thread. We want to avoid any kind of readbacks from the GPU process
to the content process when doing a drawImage of a WebGL context to an AC2D
canvas.

To achieve this, we pause the AC2D recording translation with an AwaitTranslationSync
event identified by a sync-id. Then we send a request over IPDL to snapshot the
WebGL context while this pause is ongoing via a SnapshotExternalCanvas IPDL message,
which uses the sync-id to identify the snapshot safely in a table of such external
snapshots and force translation to resume. Finally, we send a ResolveExternalSnapshot
event within the recording stream to lookup the snapshot based on the sync-id and
assign it an alias that can be used within the recording stream playback for drawImage.

The sync-id mechanism acts as a sequenced fence so that multiple SnapshotExternalCanvas
requests can be encountered simultaneously from IPDL without confusing the recording
playback.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b3fa253c8dea
Accelerate canvas drawImage of a WebGL context. r=aosmond

Comment 20

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/b3fa253c8dea

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Should we move the remaining work to a new bug for better tracking?

Comment 22

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:lsalzman, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 23

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

The following patch is waiting for review from an inactive reviewer:

ID	Title	Author	Reviewer Status
D243398	Bug 1938053 - Allow WebGLContext to generate backbuffer snapshots within GPU process. r?jgilbert	lsalzman	jgilbert: Disabled

:lsalzman, could you please find another reviewer?

For more information, please visit BugBot documentation.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ebf5de026b80
Allow WebGLContext to generate backbuffer snapshots within GPU process. r=gfx-reviewers,aosmond

Comment 25

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/ebf5de026b80

Comment 26

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

The patch landed in nightly and beta is affected.
:lsalzman, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.