The default bug view has changed. See this FAQ.

Don't draw opacity:0 display items

RESOLVED FIXED in mozilla19

Status

()

Core
Layout
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: mattwoodrow, Assigned: mattwoodrow)

Tracking

unspecified
mozilla19
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
Created attachment 681605 [details] [diff] [review]
Don't draw them

It looks like the only thing we need to actually call when we have plugins inside an opacity:0 container is here:

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#1240

So it should be fine to never build layers for these, and definitely never draw them.

I do have a separate patch that still builds layers if they contain plugins, but I don't think this is necessary.

https://tbpl.mozilla.org/?tree=Try&rev=dfa91d4b607d
Attachment #681605 - Flags: review?(roc)
Comment on attachment 681605 [details] [diff] [review]
Don't draw them

Review of attachment 681605 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/base/nsDisplayList.cpp
@@ +2810,5 @@
>                                      const nsRect& aAllowVisibleRegionExpansion) {
> +  if (mFrame->GetStyleDisplay()->mOpacity == 0) {
> +    mVisibleRect.SetEmpty();
> +    return false;
> +  }

I don't want to do this; I want the plugin geometry code to keep seeing the plugin items, and that happens after ComputeVisibility. The first half of the patch is fine though.
Attachment #681605 - Flags: review?(roc) → review+
(Assignee)

Comment 2

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/05ba5f7fa647
https://hg.mozilla.org/mozilla-central/rev/05ba5f7fa647
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19

Updated

4 years ago
Assignee: nobody → matt.woodrow
OS: Mac OS X → All
Hardware: x86 → All

Comment 4

4 years ago
A lot of animations (both CSS and JS) depend on opacity transitions. Does this patch affect those animations in any way? What about the performance when an opacity transition starts?

Comment 5

4 years ago
Looking at the patch this appears to affect rendering only, but I want to confirm. We use opacity:0 elements in a few places for user interaction and need their DOM events to continue firing as expected - is this still the case after this patch?
(In reply to Chandler from comment #5)
> Looking at the patch this appears to affect rendering only, but I want to
> confirm. We use opacity:0 elements in a few places for user interaction and
> need their DOM events to continue firing as expected - is this still the
> case after this patch?

Yes.

(In reply to Florian Bender from comment #4)
> A lot of animations (both CSS and JS) depend on opacity transitions. Does
> this patch affect those animations in any way? What about the performance
> when an opacity transition starts?

That's a good question. This patch does actually mean we don't construct layers for opacity:0 elements that have animated opacity, and we probably should. Filed bug 813722 with a patch for that.
Depends on: 813722
You need to log in before you can comment on or make changes to this bug.