Closed Bug 896703 Opened 12 years ago Closed 10 years ago

Siesta example dashboard loads very slowly

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
16 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mats, Unassigned)

References

(
URL
)

Details

Attachments

(3 files)

ACMQyd9x.dms
9.16 MB, text/plain
Details
New profile dump
9.03 MB, text/plain
Details
saWI0Oyq.dms
1.52 MB, text/plain
Details
Attached file ACMQyd9x.dms —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36 Steps to reproduce: Open our web app online (A JS testing tool called Siesta) Actual results: Firefox freezes on Mac (Macbook Pro Retina). Tried on FF22 and Nightly. Works fine on Win FF, Chrome and all others. Suspect something to do with HTML5 web fonts. Expected results: No freeze
According to the profile 46% of time is at http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxContext.cpp#303 41% if time is at http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsAppShell.mm#815
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics
Ever confirmed: true
Product: Firefox → Core
Summary: freeze → freeze loading Siesta example dashboard
I see this on Aurora (24), but not on the latest nightly (2013-07-23).
(In reply to Milan Sreckovic [:milan] from comment #3) > I see this on Aurora (24), but not on the latest nightly (2013-07-23). I do see it on the nightly one day before (2013-07-22), though it is not as bad as Aurora. Not convinced this is in graphics.
(In reply to Milan Sreckovic [:milan] from comment #4) > (In reply to Milan Sreckovic [:milan] from comment #3) > > I see this on Aurora (24), but not on the latest nightly (2013-07-23). > > I do see it on the nightly one day before (2013-07-22), though it is not as > bad as Aurora. Not convinced this is in graphics. Though, perhaps the improvement is related to bug 896129.
Any idea of a workaround? If I delete 'siesta-all.css' from the page includes, all works fine...
This is the "offending" line of CSS. background-image : linear-gradient(rgba(221, 221, 221, .3) 1px, transparent 1px), linear-gradient(90deg, rgba(221, 221, 221, .3) 1px, transparent 1px); Removing it, all is good!
How do you reproduce these hangs? Just loading http://www.bryntum.com/examples/siesta-latest/examples/browse-all-desktop.html isn't enough to do it. Neither (at least in my tests) is clicking on the "Run all" button. I tested with FF 22 on a Retina MacBook Pro.
Hehe, we released a new version without those lines of CSS so it won't be reproducible online anymore :) Old version where this is reproducible can be found here (until we do another Siesta release, typically in 2w): http://www.bryntum.com/examples/siesta-latest-old/examples/browse-all-desktop.html
OK, thanks. Even that page doesn't "hang", but it does load very slowly. The window also redraws very slowly when you resize it. I'll try to get some representative stack traces (which are often much more informative than a profile). Even with the old version, running the tests (e.g. clicking on the "Run all" button) doesn't cause bad behavior. Does that match your results? By the way, if at all possible please give us a "permanent" link to your "old version" -- one that will work for at least (say) six months. I suspect this isn't going to be an easy bug to fix :-(
The "old version" loads slowly even on a non-Retina Mac.
The "old version" loads very snappily in FF 15.0.1. It's much slower in FF 16, but not nearly as bad as it is now. Things seem to get as bad as now only with FF 18. I'll see if I can find one or both of these regression ranges in mozilla-central nightlies.
Summary: freeze loading Siesta example dashboard → Siesta example dashboard loads very slowly dashboard
Summary: Siesta example dashboard loads very slowly dashboard → Siesta example dashboard loads very slowly
The time required to load http://www.bryntum.com/examples/siesta-latest-old/examples/browse-all-desktop.html doubled with the firefox-2012-09-30-03-06-10-mozilla-central nightly -- which accounts for the FF 16/18 regression. This implies the following regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c09a0c022b2e&tochange=a680fd777c3b
Oops, it's actually the patch for bug 674373 (or part of it) that caused this particular regression. Turning off HiDPI support (by setting gfx.hidpi.enabled to -1) makes it go away on a Retina MacBook Pro.
Here's the range for the FF 15/16 regression. Unfortunately the 2012-07-07 mozilla-central nightly is missing, so this range is more than one day long: firefox-2012-07-06-07-51-26-mozilla-central firefox-2012-07-08-03-05-43-mozilla-central http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a8f682801a6d&tochange=1751d97cc9e4
Once again it's just a guess, but I suspect one of the patches for bug 752187, which has to do with gradients.
Version: 25 Branch → 16 Branch
Tomorrow I'll hg bisect the FF 15/16 regression range. I'll make this bug block the "guilty" patch.
(In reply to Milan Sreckovic [:milan] from comment #4) > (In reply to Milan Sreckovic [:milan] from comment #3) > > I see this on Aurora (24), but not on the latest nightly (2013-07-23). > > I do see it on the nightly one day before (2013-07-22), though it is not as > bad as Aurora. Don't see the problem in nightly 2013-07-29. If it is gradients, seeing the problem in 2013-07-22, but not in 2013-07-23 would match three gradient bugs fixed on the 22nd: bug 895135, bug 895646 and bug 893977.
(Following up comment #10) > By the way, if at all possible please give us a "permanent" link to > your "old version" -- one that will work for at least (say) six > months. I suspect this isn't going to be an easy bug to fix :-( Never mind. I've created a mirror of it here: http://people.mozilla.com/~stmichaud/bmo/bugzilla896703/www.bryntum.com/examples/siesta-latest-old/examples/browse-all-desktop.html
URL: http://www.bryntum.com/examples/siest... → http://people.mozilla.com/~stmichaud/...
The FF 15/16 regression was triggered by the following patch: http://hg.mozilla.org/mozilla-central/rev/1f3a325d58a4 Bug 752187 - Part 7: Add aIsLegacy parameter to parsing functions. r=dbaron author Masatoshi Kimura <VYV03354@nifty.ne.jp> Sat Jul 07 10:27:08 2012 -0400 (at Sat Jul 07 10:27:08 2012 -0400) But (as best I can tell) all this does is introduce support for the "linear-gradient" keyword (as opposed to "-moz-linear-gradient"). So this patch didn't *cause* this bug -- it was there all along.
I also see a marked improvement between the following two nightlies: firefox-2013-07-22-03-02-26-mozilla-central firefox-2013-07-23-03-02-05-mozilla-central http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2268ff80683a&tochange=5ceea82a79c7 Next I'll try to find which patch or patches are responsible for it.
The following patch seems to be responsible for all the improvement: http://hg.mozilla.org/mozilla-central/rev/9497f8c1a115 Bug 895135. Avoid normalizing gradients to a smaller interval than 0..1. r=roc author Jeff Muizelaar <jmuizelaar@mozilla.com> Sat Jul 20 08:58:10 2013 -0400 (at Sat Jul 20 08:58:10 2013 -0400)
BUMP: This is still reproducible, in latest FF (Mac + PC) with Firebug or native FF dev tools open.
Attached file New profile dump —
> (Mac + PC)
OS: Mac OS X → All
Hardware: x86 → All
Benoit, can you look at the two profiles - the same bug that came back, or did we regress linear gradients?
Flags: needinfo?(bgirard)
I can't reproduce the problem on my end. I see that there's siesta-all.js that takes over 2 seconds to receive from the network. There's very brief period of page load that pause the browser' main loop (~200ms). In your profile I see some time spent in Firebug. Can you test again with Firebug and let me know exactly what you think is bad. Is the browser locked up or are you spending too much time in connecting? For me I spend a total of ~4 seconds waiting on the network. Particularly the resources not served from a CDN seem to be very slow.
Flags: needinfo?(bgirard) → needinfo?(mats)
without Firebug*, preferably with a clean profile.
I see this running my local copy of Siesta too, with all scripts served from localhost. Browser frozen for about 15-20 seconds. Would it help if I gave you a screenshare demo over Skype? My id is mats.bryntse.
Flags: needinfo?(mats)
Perhaps, but first can you grab another profile but first set the following preferences with the Gecko Profiler add-on: profiler.interval: 50 profiler.entries: 250000 Stop/Start the profiler after tweaking these preferences, load the page and hit Analyze within 2-3 seconds after the page load. This will give a profile that will last the full 20 seconds of page load you experience.
Attached file saWI0Oyq.dms —
profile with Jank only set
Unfortunatly the main thread was not sampled at all =\. I've never seen this before. Try unselecting 'Multi-thread' and profiling again.
Multi-thread was never enabled when I did these profiles. One more try, please ping me on Skype if this log doesn't help. http://people.mozilla.org/~bgirard/cleopatra/#report=c67a64bffe8c1d96d20bb4fa99994091bb289dd0
We had a quick conversation on Skype. The remaining performance issues are only with Firebug open. My understanding is Firebug is using old APIs that aren't maintained anymore and that the new Firebug extension will move to complement the built-in devtools: https://getfirebug.com/wiki/index.php/Firebug.next Resolving as WORKSFORME since the original gradient issues was resolved but the patch landed in another bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: