Closed Bug 799956 Opened 7 years ago Closed 7 years ago
Slow scrolling in nightlies when using opacity < 1
4.27 KB, text/html
4.58 KB, text/html
1.26 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121008031745 Steps to reproduce: Scrolling is slow on a page with lots of partially transparent elements. Actual results: Somewhere between the latest stable release and the current nightly, scrolling performance regressed. It is now sluggish and jerky.
Attachment #669970 - Attachment mime type: text/plain → text/html
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics: Layers
Ever confirmed: true
Product: Firefox → Core
I can reproduce on osx.
When using rgba() with an alpha of 0.85 instead, scrolling is without lag. (Of course, this is not a general replacement, since things like images and replaced content are not affected by (background-)color: rgba(). This is probably not really a useful test case, but I am attaching it nonetheless. Hah.
Attachment #670102 - Attachment mime type: text/plain → text/html
Hi, Paul or Jan, could you post the graphics section of about:support please?
Reformatted for legibility (the table structure is not copied correctly): Device ID 0x 407 GPU Accelerated Windows 2/2 OpenGL Vendor ID 0x10de WebGL Renderer no information AzureCanvasBackend quartz AzureContentBackend none AzureFallbackCanvasBackend none For completeness' sake, here is the "Graphics/Display" section from system_profiler: Graphics/Displays: NVIDIA GeForce 8600M GT: Chipset Model: GeForce 8600M GT Type: GPU Bus: PCIe PCIe Lane Width: x16 VRAM (Total): 256 MB Vendor: NVIDIA (0x10de) Device ID: 0x0407 Revision ID: 0x00a1 ROM Revision: 3175 Displays: Color LCD: Resolution: 1440 x 900 Pixel Depth: 32-Bit Color (ARGB8888) Main Display: Yes Mirror: Off Online: Yes Built-In: Yes Display Connector: Status: No Display Connected
On Win 7 with FF19, scrolling seems to be normal.
Graphics Device ID 0x 8a2 GPU Accelerated Windows 1/1 OpenGL Vendor ID 0x10de WebGL Renderer no information AzureCanvasBackend quartz AzureContentBackend none AzureFallbackCanvasBackend none
Seems to have regressed between build ID 20120928030544 (good) and build ID 20120929030624 (bad). Good: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-28-03-05-44-mozilla-central/firefox-18.0a1.en-US.mac.dmg Bad: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-29-03-06-24-mozilla-central/firefox-18.0a1.en-US.mac.dmg Tested using a new profile.
Sorry to keep spamming, but here is the pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=895f66c4eada&tochange=c09a0c022b2e
(In reply to Jan Moesen from comment #9) > Sorry to keep spamming, but here is the pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=895f66c4eada&tochange=c09a0c022b2e Thanks for all the info, it's all useful, not spam :-) Nothing in there strikes me as that suspicious - I would expect a change to layers to cause this (opacity, scrolling = layers to me), but then all the DLBI patches landed there, so that could affect this somehow.
Definitely a DLBI regression, I'll take this.
Assignee: nobody → matt.woodrow
We were hitting component alpha flattening (even on accelerated layers) on our inactive (BasicLayers) layer trees. Pain ensues.
I think the BasicLayerManager for inactive layers should return true for AreComponentAlphaLayersEnabled().
Attachment #671316 - Flags: review?(roc) → review+
Duplicate of this bug: 795322
For bug 795322, panning on e.me sucks rocks on https://hg.mozilla.org/integration/mozilla-inbound/rev/1bca31fd0e58, and back up to 60fps on https://hg.mozilla.org/integration/mozilla-inbound/rev/65652fcb58dc . \o/ Transferring blocking-basecamp+ to this bug. Matt, do you mind requesting aurora approval for this when you're comfortable with the bake time? I don't understand this patch very well so I don't feel comfortable writing up a risk analysis.
blocking-basecamp: --- → +
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
> Transferring blocking-basecamp+ to this bug. > > Matt, do you mind requesting aurora approval for this when you're > comfortable with the bake time? I don't understand this patch very well so > I don't feel comfortable writing up a risk analysis. +1, if we can get this landed on Aurora (assuming risk is manageable), that would be great. Thanks.
Hey Ryan, this bug is blocking-basecamp+, but since it's not zero risk for desktop/android, we need explicit approval for it. Sorry, the rules are a little confusing and unobvious :(. mattwoodrow/roc/akeybl, what would you guys like to do here?
I probably won't be able to back this out until tomorrow, so you'll need to do it if that's what they decide.
Comment on attachment 671316 [details] [diff] [review] Only flatten component alpha layers that are part of a widget layer tree v2 [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 539356 User impact if declined: Unnecessary invalidation, has a significant performance impact for b2g. Testing completed (on m-c, etc.): Been on m-c for a few days without issue, confirmed that it fixes b2g performance issues. Risk to taking this patch (and alternatives if risky): Should be fairly low risk, changes code paths for text inside transform, but changes it to a simpler one (and essentially reverts behaviour to pre-DLBI behaviour). String or UUID changes made by this patch: None
Attachment #671316 - Flags: approval-mozilla-aurora?
(In reply to Ryan VanderMeulen from comment #22) > I probably won't be able to back this out until tomorrow, so you'll need to > do it if that's what they decide. No worries --- I'll back out if we don't get approval Real Soon Now. Thanks for helping get this stuff landed, as always :).
Backed out https://hg.mozilla.org/releases/mozilla-aurora/rev/7405fdfe1b89 /me eagerly waiting approval to get re-landed!
(In reply to Matt Woodrow (:mattwoodrow) from comment #23) > Risk to taking this patch (and alternatives if risky): Should be fairly low > risk, changes code paths for text inside transform, but changes it to a > simpler one (and essentially reverts behaviour to pre-DLBI behaviour). I like pre-DLBI behavior, and this is blocking-basecamp+. I think this risk is manageable. Approving for Aurora 18.
Attachment #671316 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Music to my ears. https://hg.mozilla.org/releases/mozilla-aurora/rev/e94f1c37f8ed
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0 Verified as fixed in Firefox 19 Beta 5 (BuildID: 20130206083616), latest Aurora (BuildID: 20130208042018) and latest Nightly (BuildID: 20130208031053)
You need to log in before you can comment on or make changes to this bug.