Last Comment Bug 811831 - Don't draw opacity:0 display items
: Don't draw opacity:0 display items
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla19
Assigned To: Matt Woodrow (:mattwoodrow)
:
Mentors:
Depends on: 813722
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-14 11:55 PST by Matt Woodrow (:mattwoodrow)
Modified: 2012-11-20 13:40 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Don't draw them (2.13 KB, patch)
2012-11-14 11:55 PST, Matt Woodrow (:mattwoodrow)
roc: review+
Details | Diff | Splinter Review

Description Matt Woodrow (:mattwoodrow) 2012-11-14 11:55:37 PST
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
Comment 1 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-11-14 12:44:59 PST
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) 2012-11-14 14:46:18 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/05ba5f7fa647
Comment 3 Ryan VanderMeulen [:RyanVM] 2012-11-14 18:51:20 PST
https://hg.mozilla.org/mozilla-central/rev/05ba5f7fa647
Comment 4 Florian Bender 2012-11-17 06:08:55 PST
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 2012-11-17 11:28:18 PST
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) (Exited; email my personal email if necessary) 2012-11-20 13:40:24 PST
(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.

Note You need to log in before you can comment on or make changes to this bug.