All users were logged out of Bugzilla on October 13th, 2018

[Slow animation when compared to chrome] Case 2: js1k hair poking demo.




8 years ago
2 years ago


(Reporter: kamathln, Unassigned)



Firefox Tracking Flags

(Not tracked)




(4 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre

My Machine is

I am running Debian 32 

Reproducible: Always

Reproducible: Always

Comment 1

8 years ago
Created attachment 483387 [details]
video showing comparison of performances of animation on said URL on chrome and ff
Keywords: testcase
Hmm.  Are you able to do a profile?  My best guess here is that this is completely graphics-bound....

(Needless to say, I can't reproduce on neither a Mac or a Dell Linux box whose X server is on the Mac..... otherwise I'd be profiling myself.)

Comment 3

8 years ago
Created attachment 483851 [details]
jprof report.
Attachment #483851 - Attachment mime type: text/plain → text/html
Hmm.  Why just 500 samples?  What resolution was that done at?

Also, what does sysprof say?

(fwiw, that profile is indicating about 50% time on trace, but the sample count is low enough it's hard to say more)

Comment 5

8 years ago
On my rather fast laptop sysprof shows that X Server takes ~50%, 
and in Gecko most of the time is under _cairo_gstate_stroke.

Comment 6

8 years ago
Created attachment 483961 [details]
sys prof report

:smaug on IRC wished for a plain text file. Uplaoding a compressed xml from sysprof. Please bear while I try to find a way to get a "readable" format.
FTR, --enable-mobile-optimize turns on client-side (i.e. no XRender) rendering for gtk2.  That hasn't been tested with desktop FF though, to my knowledge.

Comment 8

8 years ago
Thanks cjones. Following this advice on IRC, its currently being compiled on my machine. //That hasn't been tested with desktop FF though//. If you can guide me through, I might be able to run some tests (if the build runs successfully).
The most important thing here is perf.  If client-side rendering is much faster than XRender on your netbook, we can worry about fixing tests and how to enable it.  If it's not faster, ah well, we learned something.

I can fire off a patch to our test infrastructure and get test results back pretty fast, no need to worry about that ;).

Comment 10

8 years ago
Created attachment 484255 [details]
sys prof log of ff with  --enable-mobile-optimize
(In reply to comment #10)
> Created attachment 484255 [details]
> sys prof log of ff with  --enable-mobile-optimize

This profile shows us spending ~10% in JS and 54.33% of the time under _cairo_surface_fallback_stroke, under nsCanvasRenderingContext2D::Stroke.  This test may be forcing cairo into a slow path; the gfx folk could extract more info.
Component: General → Graphics
QA Contact: general → thebes
This demo runs very well for me on D2D. On GDI it's a tiny bit worse but it still performs just fine. So presumably this has something to do with how we stroke on Linux, this is somewhat strange since this should be close to how we stroke on GDI.
Comment hidden (offtopic)

Comment 14

2 years ago
Seems to be Silky smooth now on my Firefox 54.0a1. 
But my current machine is an 
Asus X550L with 
   Quad core 64 bit Intel I7
   Haswell Integrated Graphics + GeForce 610M/710M/820M Controller
   8GB RAM

So someone might want to test it on slower machines before closing this?

Comment 15

2 years ago
Continuing #14 :
Current config :
    GTK theme: Menta (Seems to be using the Murrine Engine)
    Cairo Engine Version: 1.14.0-2.1+deb8u1
You need to log in before you can comment on or make changes to this bug.