Open Bug 604578 Opened 14 years ago Updated 11 days ago

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

Categories

(Core :: Graphics: Canvas2D, defect)

x86
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: kamathln, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(4 files)

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 http://www.lapspecs.com/wiki/asus+eee+pc+904ha

I am running Debian 32 

Reproducible: Always

Reproducible: Always
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.)
Attached file 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)
On my rather fast laptop sysprof shows that X Server takes ~50%, 
and in Gecko most of the time is under _cairo_gstate_stroke.
Attached file 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.
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 ;).
(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.
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
   Debian64

So someone might want to test it on slower machines before closing this?
Continuing #14 :
Current config :
    GTK theme: Menta (Seems to be using the Murrine Engine)
    Cairo Engine Version: 1.14.0-2.1+deb8u1
Severity: normal → S3
Severity: S3 → --
Component: Graphics → Graphics: Canvas2D
Severity: -- → S3

14 years later, this does not seem to happen on my current system. I think this can be closed.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: