[Webkit-unassigned] [Bug 193665] [iOS] Tiles not created in large scrollable iframes

[bugzilla-daemon at webkit.org]

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

--- Comment #13 from Simon Fraser (smfr) <simon.fraser at apple.com> ---
Comment on attachment 360596
  --> https://bugs.webkit.org/attachment.cgi?id=360596
wip

View in context: https://bugs.webkit.org/attachment.cgi?id=360596&action=review

>> Source/WebCore/page/scrolling/ScrollingStateFrameScrollingNode.h:-109
>> -    // only used on the Mac.
> 
> Do we understand the history here, and why your removal doesn't break something?

This was added in https://trac.webkit.org/r168244

> Source/WebCore/page/scrolling/ScrollingStateScrollingNode.h:59
> +        ScrollContainerLayer,

We should rename the layer on the base class to be just "layer", not "ScrollLayer", and we should actually set it to the main graphicsLayer() for scrolling nodes (but the scrolling tree may never use it).

>> Source/WebCore/rendering/RenderLayerCompositor.h:564
>> +    RefPtr<GraphicsLayer> m_scrollContainerLayer;
> 
> The "that moves" is confusing. How does this layer move its content? The moving is done by setting bounds origin or position on m_scrollLayer, right? This layer doesn't control that.

For iOS, the moving is done by setting boundsOrigin on this layer. For macOS, we set the position of m_scrollLayer. I think the best option is to hide that difference, and just make sure that code that moves layers around has access to both these layers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190130/b3a661b2/attachment.html>