On Sat, Feb 22, 2014 at 8:48 AM, Patrick Walton <pcwal...@mozilla.com>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. 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. 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 _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
