Meta bug to track perf regressions that we have without SkiaGL.

Hi, this seems related to a few other reports about gl.texImage2D performance. I'm seeing a large performance difference vs Chrome here. In case that's useful the tickets I found are: 1486454, 1246410, 980749, 999700.

Lee, what kind of priority should this bug have? What are the options we have specifically on MacOS where we seem to always use Skia?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #2)

Lee, what kind of priority should this bug have? What are the options we have specifically on MacOS where we seem to always use Skia?

This is at least lower priority in H1 due to bigger issues with WR and SW-WR roll-out that are far more pressing to solve. Overall priority of this will probably be reevaluated later in the year if we make more progress on the WR front. This specific meta bug only exists for the moment to catalogue known cases and collect data, but we are not at a stage where that data is actionable as of yet.

There is also https://www.kleineschule.com.de/OnlineSpiele/BilderSudoku1.html, which is a pretty simple game, but constantly consumes 80 - 100% CPU.

Dropping this off of qf triage queue, per comment 3. (Also, metabugs typically don't fall into the [qf] bucket.)

I stumbled over the following Google update regarding switching the renderer for Google docs to Canvas:
https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html

As such I wonder if that could have any impact on our side and the performance of using Google docs in Firefox. At least the example document doesn't seem to cause issues.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #6)

I stumbled over the following Google update regarding switching the renderer for Google docs to Canvas:
https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html

As such I wonder if that could have any impact on our side and the performance of using Google docs in Firefox. At least the example document doesn't seem to cause issues.

We did a review of this in a gfx team meeting, and we determined that there are still essentially bigger bottlenecks on the JavaScript side amongst other things, and not so much on the actual canvas performance side, that we can't do much to actually make this faster simply by improving canvas performance.

As a data, I have a simple p5.js program I built that draws 625 rectangles and 625 lines and 1350 small (2px radius) circles each frame, and it runs at 10-11fps, a profile of it shows 80%-90% of time in CanvasRenderingContext2D.fill and CanvasRenderingContext2D.arc. Its not obvious to a casual reader how that isn't bottlenecked on the Canvas. Or perhaps the statement was that GoogleDocs is bottlenecked on other things, but other random JS will be different?

Either way, I desperately want to support Firefox on the things I create, but this sort of pervasive performance issue makes it hard.

Could you file a new bug, ideally with a URL & steps to reproduce the performance issue, with your p5.js program?

(It might very well be a version of this general meta-bug, but it might also be something distinct; and it's worth investigating that on a dedicated bug report.)

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.