Closed Bug 1602301 Opened 5 years ago Closed 5 years ago

Canvas drawImage() severe performance issue on Android

Categories

(Core :: Graphics: Canvas2D, defect)

72 Branch
Unspecified
Android
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1602299

People

(Reporter: register, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

This ticket is the same as Bug 1602299 (https://bugzilla.mozilla.org/show_bug.cgi?id=1602299), except that it deals with Android.

I draw an image on a "2d" context of an HTML5 "<canvas>" element repeatedly within an animation framework via the "window.requestAnimationFrame()" function.

I have attached a standalone HTML file which contains some JavaScript to run the little performance measurement.

Actual results:

When drawing the image over a canvas via a "2d" context, the performances are very bad on Firefox Android application (also in Firefox Focus, Firefox Nightly and Firefox Beta).

On my smartphone, a OnePlus A5010, equipped with a Snapdragon 835, running Android Oxygen v9.0.9, here are the results regarding the drawing durations, following the execution of the attached benchmark with the "Duration in milliseconds" set to its default value of 5000, "Use requestAnimationFrame" checked (as by default), "Scaling factor" set to its default value of 1 and "Use the "context.clearRect()" method in addition" unchecked (as by default):

  1. on Firefox Android v68.3.0: 14.926 ms
  2. on Firefox Beta Android v68.4: 12.955 ms
  3. on Firefox Focus Android v8.0.24 / v71.0a1-20191003093956: 12.270 ms
  4. on Chrome Android v79.0.3945.71: 0.889 ms
  5. on Edge Android v42.0.4.4052: 0.248 ms
  6. on Firefox iOS (running on an iPhone 6s, iOS v12.4.1) v20.2 (16690) : 0.166 ms
  7. on Chrome iOS (running on an iPhone 6s, iOS v12.4.1) v78.0.3904.84 : 0.193 ms

On Firefox Android and Firefox Beta Android, in order to have a descent time recording precision, the "privacy.reduceTimerPrecision" property has been set to "false" via the "about:config" page.

From my readings, this may be due to the Mercurial change https://hg.mozilla.org/releases/mozilla-beta/rev/3c6db05ccd3d, discussed in bug 1468801 (https://bugzilla.mozilla.org/show_bug.cgi?id=1468801), but I'm not sure.

This shows that the performance gap has a magnitude of about 20 times compared to the rest of the industry and compared to iOS.

Expected results:

The performance should not be decreased by a magnitude of more 40 times: this is a huge performance issue and many canvas-based applications suffer it and are now unusable on Firefox.

Note that this performance issue does not seem to occur on iOS.

If I can help, please tell me, because I really need this performance issue to be fixed, as this makes the animation technology that my company has developed unusable on Firefox macOS (and Android), while it is satisfactory on all other browsers.

OS: Unspecified → Android
Severity: normal → critical

Lee, any suggestions here?

Flags: needinfo?(lsalzman)

The recommended solution for now is to use WebGL for graphics intensive applications, which will be hardware accelerated.

Flags: needinfo?(lsalzman)

Thank you for the suggestion Lee, but if we could use the WebGL in our case, we would have used it. The problem is that some legacy code heavily depends on the "2D" context, and as you know, we cannot mix the "WebGL" and the "2D" contextes on the same canvas.

I guess that the performance issue comes from the fact that SkiaGL has been disabled from v62, and that the canvas is no longer GPU-accelerated.

  • If you know a work-around for accelerating the rendering, even with a Firefox proprietary manner, I am very interested.
  • If you know a way to mix the canvas "2D" and "WebGL" contextes on the same canvas, I'm also interested, even if it works only on Firefox.

Many libraries and applications, including ours, now suffer from this performance penalty and make them unusable, the "2D" context is still relevant as far as I understand from the W3C statements, hence it is worth having it optimised.

I guess that this is complex task, and if I can help, please tell me, I'm a senior software developer. Please, let me know.

I'm marking this as a duplicate of bug 1602299 for now. If it turns out our solution to 1602299 doesn't fully address Android, we'll reopen this.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: