Closed Bug 810592 Opened 9 years ago Closed 9 years ago

Add-ons manager has full page invalidation

Categories

(Core :: Layout, defect)

19 Branch
x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla20
Tracking Status
firefox18 + fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: mayankleoboy1, Assigned: mattwoodrow)

References

Details

(Whiteboard: [qa?])

Attachments

(2 files)

Attached file about support.txt
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0
Build ID: 20121110030714

Steps to reproduce:

1. Enable debug flash
2. open Add-ons manager.
3. Open the "get add-ons " tab
4. wait for loading the page
5. Scroll.

If you have enough Extensions or plugins to warrant a scroll, this can be repro on extensions and add-ons tab too.


Actual results:

Full page constant invalidation


Expected results:

minimal invalidation.


This also happens on FF15. So this is not a recent regression.
What is a "constant invalidation"?
it means that when you are scrolling, the page is repainting again and again.
See Also: → 807243
No regression range found with the pref —
nglayout.debug.paint_flashing has no effect: 2011-11-01 03:11:08.en-US.linux-x86_64
reproduced: 2011-11-18 03:10:05-en-US-x86_64
Blocks: dlbi
Component: Untriaged → Layout
Product: Firefox → Core
This is because the clip that we cache for display items is a stack of clips, and some components of the clip are above the frame that is scrolled.

Attempting to shift the combined clip to compensate for scrolling results in the wrong area, and with rounded corner clipping we invalidate the union of the areas.

Creating an nsDisplayOwnLayer for the iframe separates the clips so that this doesn't occur. I wonder if we want to do this for all actively scrolled frames, not just subdocuments.
Attachment #682980 - Flags: review?(roc)
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> Creating an nsDisplayOwnLayer for the iframe separates the clips so that
> this doesn't occur. I wonder if we want to do this for all actively scrolled
> frames, not just subdocuments.

I think that would work. We probably shouldn't try to do it on FF18 though!
Assignee: nobody → matt.woodrow
https://hg.mozilla.org/mozilla-central/rev/f573247bb449
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Please nominate for uplift as soon as you're confident with the change on m-c.
(In reply to mayankleoboy1 from comment #2)
> it means that when you are scrolling, the page is repainting again and again.

I'm not seeing a stable painting in Addons Manager on Nightly 20.0a1 (2012-12-02)
Comment on attachment 682980 [details] [diff] [review]
Make iframes with active scrolling build their own layer

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Not a regression, always performed badly
User impact if declined: Slow scrolling within iframes with rounded rect clipping.
Testing completed (on m-c, etc.):  Been on m-c for a week.
Risk to taking this patch (and alternatives if risky): Fairly low risk, just changes how we break up the retained content.
String or UUID changes made by this patch: None
Attachment #682980 - Flags: approval-mozilla-beta?
Attachment #682980 - Flags: approval-mozilla-aurora?
Comment on attachment 682980 [details] [diff] [review]
Make iframes with active scrolling build their own layer

This is a "regression" from DLBI. Approving for Aurora/Beta given where we are in the cycle and the risk profile of this fix.
Attachment #682980 - Flags: approval-mozilla-beta?
Attachment #682980 - Flags: approval-mozilla-beta+
Attachment #682980 - Flags: approval-mozilla-aurora?
Attachment #682980 - Flags: approval-mozilla-aurora+
Is this patch present in the latest Nightly ?
(In reply to mayankleoboy1 from comment #15)
> Is this patch present in the latest Nightly ?

It should be, but I don't think it's really fixed as I already said in comment 11. The same unstable painting is seen in FF 18b3.
OS: Windows 7 → All
Depends on: 820754
FWIW, with HWA off, the issue is much worse.
[qa?] based on comment 16
Whiteboard: [qa?]
You need to log in before you can comment on or make changes to this bug.