1907921 - drawImage performance lack in Windows

Status: RESOLVED WORKSFORME

(Core :: Graphics: Canvas2D, defect, P3)

Description

[tzvetelin.vassilev]

Steps to reproduce:

Make sequence of CanvasRenderingContext2D drawImage calls

Actual results:

Draw is rendered with big delay. You can find a sample here:

https://willtech.wacom.com/web-issues/firefox/canvas-performance-issue.html

The problem is observed in Windows only. This sample is executed for ~7 sec under Firefox MacOS / Linux, but in Windows it takes ~24 sec.

Expected results:

Draw for 7 sec or less

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

Comment 1

[Brad Werth [:bradwerth]]

I attempted to replicate this on my Windows machine and it run in about the same time as my macOS machine. Perhaps there is something specific about your setup that is triggering this issue. Would you please:

1. Navigate to "about:support" and copy the text from the Graphics section and add it to this Bug as an attachment.
2. Install the Firefox Profiler by navigating to "profiler.firefox.com" and make a recording of the issue on your system with the Graphics preset. Upload that profile and add the link to it to this Bug.

If you do this, we might be able to understand and fix the issue.

Comment 2

[Martin Nenov]

Attachment: Graphics.txt

Troubleshooting Information -> Graphics.

Comment 3

[Martin Nenov]

Firefox profiler recording with graphics setting.
https://share.firefox.dev/3xUS9On

Comment 4

[Martin Nenov]

Attachment: 2024-07-16 10-27-25-firefox-performance.mp4

I have observed a significant difference in the performance of the Firefox browser when using the Firefox Profiler to capture a recording versus when no recording is being captured. To illustrate this issue, I have uploaded a video demonstrating the problem. Please let me know if I can provide any additional information or logs.

Comment 5

[Brad Werth [:bradwerth]]

(In reply to Martin Nenov from comment #4)

I have observed a significant difference in the performance of the Firefox browser when using the Firefox Profiler to capture a recording versus when no recording is being captured. To illustrate this issue, I have uploaded a video demonstrating the problem.

Thank you. Interesting! The canvas performance speeds up when the profile is being recorded. That is very strange, but it explains why the the profile in comment 3 looks normal-ish and is only 9 seconds long. Perhaps something with the draw timer tick / refresh rate being tied to page content. We will discuss and figure out next things to try.

Comment 6

[Mayank Bansal]

Something to do with SetTimeout in your demo? If yes, this is a known issue. I think the suggestion is to not use SetTimeout .
Cc :mstange

Comment 7

[Brad Werth [:bradwerth]]

(In reply to Mayank Bansal from comment #6)

Something to do with SetTimeout in your demo? If yes, this is a known issue. I think the suggestion is to not use SetTimeout .
Cc :mstange

Perhaps the known issue is Bug 1814951? Needinfo for Markus.

Comment 8

[Mayank Bansal]

Martin, please see these relavent links :

https://bugzilla.mozilla.org/show_bug.cgi?id=1566900#c15
https://discourse.mozilla.org/t/webgl-application-speeds-up-while-profiler-is-running/49557/6

The recommendation is to NOT use Settimeout. Instead, use requestAnimationFrame() .

Comment 9

[tzvetelin.vassilev]

(In reply to Mayank Bansal from comment #8)

Martin, please see these relavent links :

https://bugzilla.mozilla.org/show_bug.cgi?id=1566900#c15
https://discourse.mozilla.org/t/webgl-application-speeds-up-while-profiler-is-running/49557/6

The recommendation is to NOT use Settimeout. Instead, use requestAnimationFrame() .

Yes, real application is using requestAnimationFrame but the problem appears when more than one draw is used inside current animation frame.

Comment 10

[Markus Stange [:mstange]]

Could you attach a testcase which reproduces the performance problem from your application more faithfully? I agree with Mayank that the linked testcase is just a test of Windows timer resolution and not of drawing performance.

Comment 11

[Brad Werth [:bradwerth]]

Setting to P3 until we have evidence of bad draw performance (versus just bad timer resolution, which might be Bug 1814951).

Comment 12

[Martin Nenov]

After conducting additional tests, we have determined that there is no performance issue associated with the CanvasRenderingContext2D drawImage calls.

Comment 13

[Mayank Bansal]

Glad to hear!
Just curious if you made any changes to code on your end, or was it something else?

Comment 14

[Martin Nenov]

We removed the setTimeout function and performed a test where we tried to draw as much as possible in a single animation frame. Firefox performed quite well in this test.

Comment 15

[Mayank Bansal]

Thanks for the update.
I will close this bug for now. But feel free to create a new bug if you see any issue in future.