FrameView vs RenderView

[Shawn Singh]

Hello Blinkers,

1. What is the intended purpose of FrameView and RenderView?

2. Why does FrameView deal with top-level scrolling instead of
RenderView (or the RenderView's corresponding RenderLayer)?

3. Would it make sense if we moved all rendering / scrolling logic
from FrameView into RenderView instead? Then FrameView seems to be
actually just a "LayoutEngine" and should be renamed?

4. Scrolling on a scrollable area should never affect layout, right?

Details about why I'm asking:

Fixed-position layers have incorrect repaint rects when the
repaintContainer is a descendant of the fixed-position containing
block. https://codereview.chromium.org/23523046/ . These layers need
to know the scroll offset in order to correctly compute their repaint
rect. However, this scroll offset is only known by the FrameView.
The patch I have proposed will fix the specific scenario by modifying
FrameView scrolling code, where scrollPosition() is known. But if any
other code uses the layer's repaint rects, they would still be using
incorrect repaint rects.


Thanks,
~Shawn

[James Robinson]

In the olden days when dragons roamed the earth and WebKit had many ports, some ports would sometimes back a Frame with a native platform widget (such as an NSScrollView) which would handle (some of) the responsibilities of scrolling and rendering.  To support this, FrameView had branches in many of its internal functions that looked like "if (platformWidget()) doSomethingDifferent".  RenderLayers did not have this consideration and thus didn't have these branches.  If you are curious or nostalgic, you can see these branches here: http://trac.webkit.org/browser/trunk/Source/WebCore/page/FrameView.cpp.

In Chromium (and WebKit2, fwiw), FrameViews are never backed by 'native' widgets.  We've removed the platformWidget() branches but a number of design choices driven by that constraint still live on.  We still have an updateWidgets() step on FrameView that used to be because the FrameView widget was responsible for its child widgets.  We still have a number of codepaths related to the FrameView for a non-root Frame being a 'root' in the native widget hierarchy.  *Most* of the difference in FrameView and RenderLayer scrolling boils down to this.  I think it'd be a good thing to unify these scrolling paths.  This will be a lot easier once Blink is always communicating with a compositor, since today the 'root' is special.

- James

[Elliott Sprehn]

On Thu, Sep 12, 2013 at 4:33 PM, Shawn Singh <shawn...@chromium.org> wrote:

Hello Blinkers,

1. What is the intended purpose of FrameView and RenderView?

FrameView is the viewport, RenderView is the Initial Containing Block. When you scroll at the top level you move the FrameView up and down (or left and right). The RenderView never moves though, since the Document itself doesn't have a concept of scrolling, instead it remains stuck at the top of the page and is sized to the viewport.

See: https://www.webkit.org/blog/116/webcore-rendering-iii-layout-basics/

Specifically this part seems relevant:

"""

If the document is scrolled, then the initial containing block [RenderView] will be moved offscreen. It is always at the top of the document and sized to the viewport [FrameView]. One area of confusion that people often have with the initial containing block is that they expect it to somehow be outside the document and part of the viewport.

"""

2. Why does FrameView deal with top-level scrolling instead of
RenderView (or the RenderView's corresponding RenderLayer)?

Because FrameView is the viewport and that's what's moving when you scroll at the top level. The RenderView doesn't move, and is (often) smaller than the Document itself.

3. Would it make sense if we moved all rendering / scrolling logic
from FrameView into RenderView instead?  Then FrameView seems to be
actually just a "LayoutEngine" and should be renamed?

Maybe; it might be kind of awkward since the top level scrolling behavior is different and there's special rules. For example we never reverse the scrollbar side based on writing mode which, according to Tony Chang, was because it was jarring to users to have the top level scrollbar jump from left to right based on the direction of pages in different tabs. The scrollbars inside the page (e.x overflow: scroll) do change sides though.

You should just post a patch and see what it looks like. :)

 

4. Scrolling on a scrollable area should never affect layout, right?

I think they can, for example position: sticky elements go from being in flow to being "stuck" if they hit a certain spot which makes them jump out of flow changing the layout of the page. Presumably we leave some kind of space in there so the things don't collapse? I think ojan knows how this works.

Details about why I'm asking:

Fixed-position layers have incorrect repaint rects when the
repaintContainer is a descendant of the fixed-position containing
block.  https://codereview.chromium.org/23523046/ .  These layers need
to know the scroll offset in order to correctly compute their repaint
rect.  However, this scroll offset is only known by the FrameView.
The patch I have proposed will fix the specific scenario by modifying
FrameView scrolling code, where scrollPosition() is known.  But if any
other code uses the layer's repaint rects, they would still be using
incorrect repaint rects.

Sounds like we might need better abstractions here.

- E 

[Tony Chang]

On Thu, Sep 12, 2013 at 7:30 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Sep 12, 2013 at 4:33 PM, Shawn Singh <shawn...@chromium.org> wrote:

Hello Blinkers,

1. What is the intended purpose of FrameView and RenderView?

FrameView is the viewport, RenderView is the Initial Containing Block. When you scroll at the top level you move the FrameView up and down (or left and right). The RenderView never moves though, since the Document itself doesn't have a concept of scrolling, instead it remains stuck at the top of the page and is sized to the viewport.

See: https://www.webkit.org/blog/116/webcore-rendering-iii-layout-basics/

Specifically this part seems relevant:

"""

If the document is scrolled, then the initial containing block [RenderView] will be moved offscreen. It is always at the top of the document and sized to the viewport [FrameView]. One area of confusion that people often have with the initial containing block is that they expect it to somehow be outside the document and part of the viewport.

"""

2. Why does FrameView deal with top-level scrolling instead of
RenderView (or the RenderView's corresponding RenderLayer)?

Because FrameView is the viewport and that's what's moving when you scroll at the top level. The RenderView doesn't move, and is (often) smaller than the Document itself.

3. Would it make sense if we moved all rendering / scrolling logic
from FrameView into RenderView instead?  Then FrameView seems to be
actually just a "LayoutEngine" and should be renamed?

Maybe; it might be kind of awkward since the top level scrolling behavior is different and there's special rules. For example we never reverse the scrollbar side based on writing mode which, according to Tony Chang, was because it was jarring to users to have the top level scrollbar jump from left to right based on the direction of pages in different tabs. The scrollbars inside the page (e.x overflow: scroll) do change sides though.

In case anyone is curious, I learned about this here:

https://bugs.webkit.org/show_bug.cgi?id=54623#c16

That said, I think it would be easy to handle this special case if we merged ScrollView and FrameView.  It would probably also make it easy to fix RTL iframes having the scrollbar on the wrong side (it should go on the left: https://bugs.webkit.org/show_bug.cgi?id=54623#c67 ).

[Mike Sherov]

Mike Sherov

Chief Technologist

SNAP Interactive, Inc. | Ticker: STVI

http://snap-interactive.com | http://ayi.com

On Sep 12, 2013, at 10:31 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Sep 12, 2013 at 4:33 PM, Shawn Singh <shawn...@chromium.org> wrote:

Hello Blinkers,

1. What is the intended purpose of FrameView and RenderView?

FrameView is the viewport, RenderView is the Initial Containing Block. When you scroll at the top level you move the FrameView up and down (or left and right). The RenderView never moves though, since the Document itself doesn't have a concept of scrolling, instead it remains stuck at the top of the page and is sized to the viewport.

I'm not sure if this bug is related, but figured I'd post it here: https://code.google.com/p/chromium/issues/detail?id=157855

The same is was reported in Webkit back in 2006. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Eric Seidel]

We still have a lot of widget-related cruft which can/should be
removed. Widgets are Scrollbars, Frames and Plugins. They're held in
a tree and ref-counted (able to live longer than the RenderObjects
they correspond to due to needing to stay alive for plugins/native
view handles).

updateWidgets is a huge hammer which should be replaced with more
surgical update mechanisms now that we don't have to support calling
out into arbitrary platform "widget" code.

I think where possible we should unify our scrolling paths. That
said, FrameView's are likely to get more opaque rather than less with
out-of-process (OOP) iframes. I think there is a good possibility for
unification/sanification of our plugin and frame pathways with OOP
iframes.