Re: [dev-servo] Dealing with fragmentation/pagination
>On Tue, Mar 11, 2014 at 1:53 AM, wrote: > >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. > > > > >How do you handle the case where two elements belong to different >fragments of the same fragmentainer but overlap in unfragmented space? Could you give me an example of that situation? It¹s not very clear to me what case you are talking about so I can only speculate. To elaborate a bit what I said in my previous email: 1. Two fragments overlap during the layout (e.g. negative margins). This case is handled correctly because layout is the step when fragmentation actually occurs. Pagination struts and other techniques are applied to actually construct the fragments internally. 2. Two fragments overlap at paint time because they¹ve been shifted somehow from their layout positions (e.g. relative positioning, transforms etc.). In WebKit, this implies the shifting objects get a so called self-painting layer. These kind of objects know how to paint themselves as groups. Using the clipping information computed during the layout, the layers can contain their fragments correctly. Also, we have the so called concept of a region range. This range is associated with an element and it represents the regions that element is flowed into. For monolithic elements (images, videos etc.) that range has a length of one. During paint time, we apply paint rejection outside of that range so even though a monolithic element is taller than the region it belongs to, it will not be painted in the following regions. This way we avoid content slicing. If you want to play around with the feature, I¹ve bootstrapped a simple example with three regions that should work on WebKit nightly: http://codepen.io/abucur/pen/lxrnk > > >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 > > Thanks, Andrei. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Dealing with fragmentation/pagination
On Tue, Mar 11, 2014 at 3:25 PM, Andrei Bucur wrote: > Could you give me an example of that situation? It¹s not very clear to me > what case you are talking about so I can only speculate. To elaborate a > bit what I said in my previous email: > 1. Two fragments overlap during the layout (e.g. negative margins). This > case is handled correctly because layout is the step when fragmentation > actually occurs. Pagination struts and other techniques are applied to > actually construct the fragments internally. > 2. Two fragments overlap at paint time because they¹ve been shifted > somehow from their layout positions (e.g. relative positioning, transforms > etc.). In WebKit, this implies the shifting objects get a so called > self-painting layer. These kind of objects know how to paint themselves as > groups. Using the clipping information computed during the layout, the > layers can contain their fragments correctly. > Suppose I have a font with very long descenders (e.g. Zapfino) and I have content like this: piffleooof where the descenders of the p and f would normally overlap the second line, but there's a fragment break between the lines. How do you stop the first line's descenders being drawn in the second fragment? Also, we have the so called concept of a region range. This range is > associated with an element and it represents the regions that element is > flowed into. For monolithic elements (images, videos etc.) that range has > a length of one. During paint time, we apply paint rejection outside of > that range so even though a monolithic element is taller than the region > it belongs to, it will not be painted in the following regions. This way > we avoid content slicing. > OK, this sounds like how I think things should work. If this approach works I wonder why you bother with clipping at all. 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
Re: [dev-servo] Dealing with fragmentation/pagination
>On Tue, Mar 11, 2014 at 3:25 PM, Andrei Bucur wrote: > >> Could you give me an example of that situation? It¹s not very clear to >>me >> what case you are talking about so I can only speculate. To elaborate a >> bit what I said in my previous email: >> 1. Two fragments overlap during the layout (e.g. negative margins). This >> case is handled correctly because layout is the step when fragmentation >> actually occurs. Pagination struts and other techniques are applied to >> actually construct the fragments internally. >> 2. Two fragments overlap at paint time because they¹ve been shifted >> somehow from their layout positions (e.g. relative positioning, >>transforms >> etc.). In WebKit, this implies the shifting objects get a so called >> self-painting layer. These kind of objects know how to paint themselves >>as >> groups. Using the clipping information computed during the layout, the >> layers can contain their fragments correctly. >> > >Suppose I have a font with very long descenders (e.g. Zapfino) and I have >content like this: >piffleooof >where the descenders of the p and f would normally overlap the second >line, >but there's a fragment break between the lines. How do you stop the first >line's descenders being drawn in the second fragment? Lines have a containing region assigned to them, determined during layout. A line is painted only inside its containing region so no overlapping is possible with lines in different fragments. > >Also, we have the so called concept of a region range. This range is >> associated with an element and it represents the regions that element is >> flowed into. For monolithic elements (images, videos etc.) that range >>has >> a length of one. During paint time, we apply paint rejection outside of >> that range so even though a monolithic element is taller than the region >> it belongs to, it will not be painted in the following regions. This way >> we avoid content slicing. >> > >OK, this sounds like how I think things should work. If this approach >works >I wonder why you bother with clipping at all. Clipping is need to correctly contain fragments of non-monolithic elements inside the fragment containers. As a more advanced example, consider this element: If "content" is flowed inside a region 100px tall, the image will overflow it with 50px. The problem is we need to clip the background of the first fragment of "content" to 100px so red is not visible in the 50px area below the region. The rest of 200px of "content" should continue in the following regions. > >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 Thanks, Andrei. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] 3/10 meeting notes on fragmentation and regions
There appears to be an issue with the list archives - apparently there’s a 3/10 meeting notes post, but it’s not there in the archives. And I missed a conversation between Andrei Bucur and Robert O’Callahan, because I’d only been looking at the archive. I’m subscribed to this list now :) From the meeting notes: > pcwalton: Sounds like CSS FRagmentation spec is tied up with Regions and >is in a lot of flux. I wonder how much is actually going to happen and >how much is not likely to happen at this point. Clear we can't implement >the spec (it doesn't work), but how much should we? I don’t see the fragmentation spec as tied up with regions at all, and there has not been much flux in this spec for quite a while. I think it would be a good idea for Servo to look into implementing all of the fragmentation spec. It’s meant to cover all of the overlapping fragmentation issues between pagination, multicol and regions - so you’ll need it for the first two even if you don’t implement the third. And both the fragmentation and regions specifications do work - as proved by the two shipping implementations (Safari and Trident) that have applications using the features. One of those applications (Fidus Writer) was even a Mozilla Festival strategic pick, and the developers are keen to have their code work with Mozilla browsers. > simonsapin: What do you mean? > pcwalton: Some parts do not terminate. dbaron said it needs to be fixed >somehow… I assume this is a misconception about the regions processing model. It usually needs one layout pass, but will sometimes need a second to size regions to their content. The model stops at the second layout pass. Unfortunately, dbaron has been characterizing this as ‘multi-pass layout’ and others apparently read ‘does not terminate’ into that. > kmc: Yes, if blink is not going to implement part of it, presumably we >should not either since nobody will use it. > jack: Yes, lots of pushback on getting rid of regions for them, not sure >if they're going to continue. Blink has decided to postpone any work on regions in favor of their short-term performance goals. But so far they have retained the regions-based rewrite of the fragmentation code. That will make it easier to resume work on regions in Blink once they achieve their current goals. I’m hoping that Servo can keep longer-term options in mind. Thanks, Alan ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 3/10 meeting notes on fragmentation and regions
> There appears to be an issue with the list archives - apparently there's a > 3/10 meeting notes post, but it's not there in the archives. And I missed > a conversation between Andrei Bucur and Robert O'Callahan, because I'd > only been looking at the archive. I'm subscribed to this list now :) I'll try and investigate. A few people have had complains over the last day or so. I'm hoping it's just a Google glitch that will resolve itself. > Blink has decided to postpone any work on regions in favor of their > short-term performance goals. But so far they have retained the > regions-based rewrite of the fragmentation code. That will make it easier > to resume work on regions in Blink once they achieve their current goals. > I'm hoping that Servo can keep longer-term options in mind. Thanks for this information. Luckily for us, our performance goals require us to tackle the hard features like fragmentation early, which is why it's on the short term agenda. We haven't yet made any specific plans about what pieces to include or where to start, but it will probably start appearing regularly in the minutes and in bugs soon. We'd certainly appreciate your feedback. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
