All users were logged out of Bugzilla on October 13th, 2018
1.55 MB, video/ogg
592.56 KB, text/html
53.75 KB, application/octet-stream
36.80 KB, application/octet-stream
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
Created attachment 483387 [details] video showing comparison of performances of animation on said URL on chrome and ff
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.)
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.
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.
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
You need to log in before you can comment on or make changes to this bug.