Closed Bug 799956 Opened 7 years ago Closed 7 years ago

Slow scrolling in nightlies when using opacity < 1

Categories

(Core :: Graphics: Layers, defect)

18 Branch
x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla19
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- verified

People

(Reporter: janmoesen_=-bugzilla-=+spamtrap, Assigned: mattwoodrow)

References

Details

Attachments

(3 files, 1 obsolete file)

Attached file scrolling.html
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
(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.
Attachment #671292 - Flags: review?(roc)
I think the BasicLayerManager for inactive layers should return true for AreComponentAlphaLayersEnabled().
Attachment #671292 - Attachment is obsolete: true
Attachment #671292 - Flags: review?(roc)
Attachment #671316 - Flags: review?(roc)
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: --- → +
https://hg.mozilla.org/mozilla-central/rev/65652fcb58dc
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 :).
(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+
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)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.