[Webkit-unassigned] [Bug 55257] Support creating compositing layers for scrollable and overflowing objects

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 4 14:38:44 PST 2011


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





--- Comment #25 from Simon Fraser (smfr) <simon.fraser at apple.com>  2011-03-04 14:38:44 PST ---
(In reply to comment #23)
> Simon, thanks for your feedback and apologies for missing to CC you on this bug, my bad!
> 
> (In reply to comment #21)
> > (From update of attachment 84779 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=84779&action=review
> > 
> > > Source/WebCore/rendering/RenderLayer.cpp:3816
> > > +        || renderer()->isRenderIFrame()
> > > +        || isComposited();
> > 
> > You can't do this; the test becomes circular. See RenderLayerCompositor::canBeComposited().
> >
> 
> But isComposited() != canBeComposited(). The problem I had is that the more generic elements that I want to composite (like overflowing DIVs) are currently not self-painting.

In the current design, non-self-painting layers cannot be composited. Changing whether a layer is self-painting will change rendering. Non self-painting layers are used for overflow (they hold a clip).

> Also I didn't want to make all kinds of elements self-painting, if they will not be composited. Since I really only know until after layout, I did the inverse logic here of saying that if we eventually made the layer composited (because it is scrollable and does overflow), we should now be returning true from isSelfPaintingLayer().
> 
> In other words, I added isComposited() to the logic here to make sure we return true for 'self-painting' after we have decided to give this layers its own graphics layer in requiresCompositingForScrollableOverflow() (without duplicating the logic).
> 
> 
> > Non-self-painting layers are used for overflow, so your changes here will break rendering in some cases.
> > 
> 
> Wouldn't RenderLayers that have a GraphicsLayer (i.e. are composited) always be self-painting? I'm probably missing something, can you elaborate on what would break?

Compositing logic should never change whether something is self-painting. We've chosen to make some replaced elements self-painting so we can accelerate them (video, plugins etc), but doing so for container elements like divs will break the web.

> 
> On the other hand, so what would happen if I created a composited layer that ends up returning 'false' from isSelfPaintingLayer()? This seems to be used quite a bit including in hit testing logic.

It don't render any content, and probably invalidates some assumptions that the compositing code makes.

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