[Webkit-unassigned] [Bug 70564] [Chromium] Make root layer always opaque

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 21 12:38:16 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=70564





--- Comment #5 from James Robinson <jamesr at chromium.org>  2011-10-21 12:38:17 PST ---
(In reply to comment #4)
> Here's why I thought it would be better to override opaque() instead:  If we set the bit for a NonComposited surface, we will have have to put checks in the code in every other place that unsets the bit to check if it's NonComposited.  And that makes more special case code than we have now. Am I wrong about this?
> 
> If not, we could check isNonComposited() rather than !m_parent in opaque().
> 
> I had thought you meant to remove the NonCompositedLayer entirely when you talked about removing special cases, but I guess that wasn't your intent.

Sorry, I wasn't expressive enough.

The current state of the world is that we have a NonCompositedContentHost object that hosts a GraphicsLayer and so, indirectly, a LayerChromium.  We want this LayerChromium to have some special behaviors (blending disabled, no border texels).  The way that is done today is by setting a special flag on the LayerChromium which is then propagated through the system and used in various places.

I think this is wrong and we should instead have NonCompositedContentHost set the more relevant bits for the behaviors it wants.  For example, to disable blending it should just set the opaque bit and then the compositor would know to disable blending.  Similarly we should be able to detect when we need border texels without relying on this bit (although that's a separate issue).

So my feedback is this: change NonCompositedContentHost to set the opaque bit correctly on its LayerChromium and then use that to control blending instead of the isNonCompositedContent() bit.  You shouldn't be messing around with how isOpaque() works, that should definitely still just be a bool on LayerChromium that works in the normal way.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list