811831 - Don't draw opacity:0 display items

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Matt Woodrow (:mattwoodrow)]

Attachment: 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

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 2

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/05ba5f7fa647

Comment 3

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/05ba5f7fa647

Comment 4

[Florian Bender]

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

[Chandler]

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?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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.