1686590 - [Bug] Very slow, choppy performance of SVG compared to Chrome on same device (example included)

Status: NEW

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

Description

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

From github: https://github.com/mozilla-mobile/fenix/issues/17216.

(This is an existing bug that unfortunately still exists: https://bugzilla.mozilla.org/show_bug.cgi?id=1289866 )

Visit this page on both Firefox nightly (fenix) and Chrome on Android: http://vallandingham.me/gates_bubbles/

Performance on Fenix is much slower.

I'm designing an online collaborate drawing tool, and Fenix is completely unusable compare to a smooth experience in Chrome. I know my application is pushing the limits sort of, so thats why I included the more simple example above. Alpha demo of our app: http://internet-paper.com/paper.html (sources https://github.com/psy0rz/etherpaint )

Try pinch-zooming on both Chrome and Fenix. Chrome has 10+fps vs Fenix <1fps.

The performance difference between the two are orders of magnitude.

Optimization tips or workarounds are welcome as well. (we're going to use simplyjs to reduce the polylines)

• Android device: LG Velvet
• Fenix version: Nightly 201224 17:00

Change performed by the Move to Bugzilla add-on.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

I'm not really seeing much difference when loading http://vallandingham.me/gates_bubbles/
and zoom.
But the github issue seems to be about various different tests.
https://github.com/mozilla-mobile/fenix/issues/17216#issuecomment-751348158 has some other case.

Comment 2

[edwin eefting]

Why has this been moved from https://bugzilla.mozilla.org/show_bug.cgi?id=1289866 to github to here??

Anyway, heres the important info (from github):

I changed the zoom to be as simple a possible, only an SVG element and viewbox zooming: https://draw.cafe/svgtest2.html

The firefox variants only seem to be slower with this specific set of circumstances. They are orders of magnitude slower when the polygons have very long segments.

All and all much faster and hopefully acceptable for our use case.

TLDR

• huge polygons have slow viewbox zooming compared to chrome.
• zooming by resizing the element instead of a viewbox zoom can be catastrophic. (while still smooth on chrome)
• tested with firefox android/firefox beta android/fenix/firefox desktop on ubuntu 20.

Comment 3

[edwin eefting]

Or another test on our actual application:

Go to https://draw.cafe/d/mozilla and compare pinch zooming on the drawing with chromium mobile vs firefox mobile. (nightly)

There's already a noticeable difference and the drawing isnt even that complex. Chromium stays smooth until the drawing starts to get really huge.

Comment 4

[edwin eefting]

I just checked with the lastest firefox nightly on a LG velvet phone: https://draw.cafe/svgtest2.html is still an order of magnitude slower compared to chromium.

Comment 5

[Daniel Holbert [:dholbert] (PTO until 2/24)]

(In reply to edwin eefting from comment #2)

Why has this been moved from https://bugzilla.mozilla.org/show_bug.cgi?id=1289866 to github to here??

Sorry for the bug ping-pong. The short version is: bug 1289866 was misclassified.

(It was filed under "Firefox for Android" which was about issues that were specific to the front end & user experience of the old "Fennec" version of Firefox-for-Android. The new "Fenix" rewrite of Firefox-for-Android uses github to track their code/issues; this is why bug 1289866 comment 9 suggested filing a github issue, and so somebody did that. But in fact, this bug seems to be an issue in Firefox's rendering engine -- it's not specific to the Android front-end -- which is why the Fenix team ended up filing a bug for it back here. They could just as well have reopened & reclassified bug 1289866, but it doesn't make too much difference. Now it's hopefully classified correctly.)

Comment 7

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Here's a performance profile that I captured of myself loading https://draw.cafe/svgtest2.html on my Pixel 4a Android phone:
https://share.firefox.dev/3oEFioK
(tangent: the screenshots track is a bit messed-up, so don't pay too much attention to it -- I filed bug 1690147 on that.)

The benchmark's final rendering looks something like:

1098ms
17ms
266ms
150ms
665ms
33ms
[etc]

...with values mostly in the hundreds of milliseconds. In contrast, Chrome renders the testcase much snappier, with 63ms as the first timestamp shown at the end, and the rest nearly all 17ms (which I think is just showing a 60fps refresh-rate; they may be performing faster than that & it's just throttled to 60fps).

So indeed, they're doing quite a bit better than us here.

The very first operation in the profile seems to be the slowest -- here's my performance profile zoomed to that range: https://share.firefox.dev/2NSCNlX

It looks like the compositor is hanging in mozilla::layers::SynchronousTask::Wait() for 851ms there, in some sort of synchronization system-call, and I don't see much happening in other threads during that time.

Markus, do you know what might be going on there, perhaps? (Or do you know who to point at this?) This probably needs someone from the graphics team to look at it and see if they can figure out what's going wrong... Moving to Graphics|WebRender for now.

Comment 8

[Markus Stange [:mstange]]

The time is probably spent in Skia on the WrWorker threads. It would be good to get a new profile that includes the RenderBackend, SceneBuild and WrWorker threads.

The mozilla::layers::SynchronousTask::Wait() is probably caused by a call to RequestScreenPixels, which Fenix does for its tab previews. The compositor side of this API should be made more asynchronous, but that's orthogonal to the SVG slowness.

Comment 9

[Daniel Holbert [:dholbert] (PTO until 2/24)]

Here's a profile with those threads included: https://share.firefox.dev/3j8y1MI

Comment 10

[Markus Stange [:mstange]]

Thanks! As expected, the WrWorker threads are busy doing Skia software rendering. https://share.firefox.dev/3oFhZv9

Comment 11

[edwin eefting]

(In reply to Daniel Holbert [:dholbert] from comment #7)

Here's a performance profile that I captured of myself loading https://draw.cafe/svgtest2.html on my Pixel 4a Android phone:
https://share.firefox.dev/3oEFioK
(tangent: the screenshots track is a bit messed-up, so don't pay too much attention to it -- I filed bug 1690147 on that.)

The benchmark's final rendering looks something like:

1098ms
17ms
266ms
150ms
665ms
33ms
[etc]

...with values mostly in the hundreds of milliseconds. In contrast, Chrome renders the testcase much snappier, with 63ms as the first timestamp shown at the end, and the rest nearly all 17ms (which I think is just showing a 60fps refresh-rate; they may be performing faster than that & it's just throttled to 60fps).

So indeed, they're doing quite a bit better than us here.

The very first operation in the profile seems to be the slowest -- here's my performance profile zoomed to that range: https://share.firefox.dev/2NSCNlX

It looks like the compositor is hanging in mozilla::layers::SynchronousTask::Wait() for 851ms there, in some sort of synchronization system-call, and I don't see much happening in other threads during that time.

Markus, do you know what might be going on there, perhaps? (Or do you know who to point at this?) This probably needs someone from the graphics team to look at it and see if they can figure out what's going wrong... Moving to Graphics|WebRender for now.

Indeed 17mS is one frame if you run at 60fps. So the optimal test would be if all lines are 17mS, but that isn't a realistic goal.

I even wouldn't mind if the first frame take long, but currently its way too slow.

I admit the test does some very extreme zooming with huge polygons to trigger the problem, but as i mentioned before: Our real application also shows significant performance difference.

Comment 12

[edwin eefting]

(In reply to Daniel Holbert [:dholbert] from comment #5)

(In reply to edwin eefting from comment #2)

Why has this been moved from https://bugzilla.mozilla.org/show_bug.cgi?id=1289866 to github to here??

Sorry for the bug ping-pong. The short version is: bug 1289866 was misclassified.

(It was filed under "Firefox for Android" which was about issues that were specific to the front end & user experience of the old "Fennec" version of Firefox-for-Android. The new "Fenix" rewrite of Firefox-for-Android uses github to track their code/issues; this is why bug 1289866 comment 9 suggested filing a github issue, and so somebody did that. But in fact, this bug seems to be an issue in Firefox's rendering engine -- it's not specific to the Android front-end -- which is why the Fenix team ended up filing a bug for it back here. They could just as well have reopened & reclassified bug 1289866, but it doesn't make too much difference. Now it's hopefully classified correctly.)

Thanks, the most important part is that you guys care. :)