Hello everyone! I'm happy to see this topic brought up in the discussion. If you want, I can give you more details about WebKit's implementation of fragmentation than what's available in the blog posts. More comments inline.
On Saturday, February 22, 2014 12:19:24 AM UTC+2, Robert O'Callahan wrote: > On Sat, Feb 22, 2014 at 8:48 AM, Patrick Walton wrote: > > > > > You mentioned that we should be thinking about fragmentation and > > > pagination now. I heard from Seth that Gecko uses multiple frames for > > > fragmentation, that this adds a lot of complexity, and that you potentially > > > wanted to try using a single frame to handle objects split across multiple > > > pages. I was wondering what your thoughts as to the best way to approach > > > this were, so that we can at least keep this in mind when reviewing > > > implementations of new features for Servo (and prototype something soon, > > > hopefully). > > > > > > > I don't have a concrete plan for how I think it should work. I have some > > thoughts, and dbaron has some other thoughts. You should also look at > > Adobe's work on fragmentation in Webkit (e.g. > > http://blogs.adobe.com/webplatform/2013/03/05/css-fragmentation-in-webkit/, > > http://blogs.adobe.com/webplatform/2013/10/28/css-regions-painting-in-webkit-and-blink/ > > ). > > > > Gecko generates one object per fragment and arranges them into an explicit > > fragment tree with correct geometry. The nice thing about this is that the > > structure is conceptually simple; it maps directly to the mental model of > > CSS. However there are some problems that make it suboptimal, IMHO. The > > biggest is alluded to in the first Adobe blog post I linked to: maintaining > > an explicit, complete fragment tree requires a lot of tree surgery during > > layout, which is both expensive and complex. When content moves between > > fragments there's a lot of "pushing" and "pulling", and in some places we > > have crazy hacks (lazy inline reparenting for example) to make it > > performant (and those hacks don't always work). > > > > Also there are real-life cases where this approach forces pathological > > behavior. For example if you have containers nested K deep, and the > > innermost container breaks over N fragments, there are K*N CSS fragments so > > you must create K*N objects. But there are alternate representations where > > you don't have one object per fragment, like the Adobe one (I think), or a > > representation that flattens everything into a list annotated with fragment > > boundaries and container box start/end points, giving you O(K + N) objects. > > > > Advanced fragmentation proposals include the ability to give fragments of > > the same box different styles. This is relatively easy in Gecko since each > > fragment has a style context. That seems more difficult with an implicit > > fragments approach, but doable. Indeed, there are problems with applying layout-time properties for fragments. For paint-time properties (backgrounds, colors etc.) it's not so difficult. The new style can be applied when painting each fragment container and restored when the paint is finished. As an advanced fragmentation feature you should take into account the fact fragment containers can have different widths. I think this topic is a bit too advanced to be detailed in a blog post so I didn't focus on it in those articles. A big chunk of complexity comes from that area. If you're interested, I can give you more information about how we tackled the problem in WebKit. > > > > The essence of the Adobe approach is that you put all the fragments in the > > same coordinate space, use struts to push content past fragment boundaries > > when necessary, and at paint time iterate over fragments and use clipping > > and transforms to draw each fragment in the right place. I think any > > approach that relies on clipping is bound to have bugs where overflowing > > content belonging to different fragments overlaps in the unfragmented > > coordinate space and is incorrectly rendered in multiple places, so I think > > you don't want to depend on clipping. An implicit fragments approach that > > generates fragments at display list construction time sounds like it should > > work. There will be some complications with overflow areas. We currently have two methods of painting content flows. The multi-column flows are painted using a special fragment structure at a layer level. For regions we use a different mechanism that's based on clipping information collected during layout. We didn't have this landed yet when I wrote those blog posts so they are a bit outdated in this regard. During the layout we construct the clippling rectangles (visual overflow) in each fragmentation container for the objects inside the fragmented flow. When a monolithic object is too large to fit a fragment container we apply different clipping rectangles for the box decorations of its container and the foreground of the object. This way the container of the object will not paint its background/borders where only the object should be painted. As a result, we can now correctly render relatively positioned object fragments by just translating the clipping area together with the objects. Transforms will follow but they shouldn't change too much besides adjusting the coordinate system to take into account fragmentation. There are still some issues left to be solved but I don't think they will affect the overall architecture. > > > > Whatever you do, I feel pretty strongly that you should not have an > > explicit fragment tree, but provide an API that allows iteration over parts > > of the fragment tree on demand. > > > > Rob > > -- > > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > > waanndt wyeonut thoo mken.o w Hope this helps, Andrei. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
