Re: Mutating the frame tree shape from reflow code.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Re: Mutating the frame tree shape from reflow code.

Emilio Cobos Álvarez
Self replying since I had a conversation with Xidorn...

So apparently we just use frames for everything that ends up being a
rect (unlike WK, for example, that doesn't mutate the "render tree"
while doing layout).

So we just create more frames / delete frames while reflowing because
we've run out of space for example, or because we managed to complete a
reflow and the rest of the in-flow continuations are now useless.

And thus probably pursuing this is much harder than what I thought in
the first time...

If people think it's still worth I'm happy to hear discussion,
otherwise, I guess you can disregard the previous email :)

 -- Emilio

On 09/12/2017 12:05 AM, Emilio Cobos Álvarez wrote:

> Hi,
> So today I was looking at a bug[1] that happens to be a combination of
> edge cases (as usual) ending up badly. In particular, a columnset frame
> removing a not-first-in-flow frame via DeleteNextInFlow that happens to
> hold the pseudo-elements of a nested display: contents element, thus
> unbinding them from the tree and breaking the counter manager invariants.
> I've noticed recently in other bug I've recently fixed a similar pattern
> (that bug crashed creating a first-letter continuation during bidi
> resolution, though the underlying issue ended up being other).
> I think the frame tree would be much easier to reason about and manage
> if it didn't mutate during reflow, though there seem to be a bunch of
> places that do that (grepping for StealFrame, CreateContinuation, ...).
> Note: I mean mutate as "creating / destroying frames", not as in "not
> change any member variable of any frame", obviously.
> My questions are (for those who know more about Gecko layout than me):
>  * Do you think it is reasonably doable to stop mutating the frame tree
> from layout?
>  * Would it be worth it? (I think it would!)
>  * Would it be reasonable to spend some time on it? (perhaps in the
> medium / long term, given right now everyone has other important things
> to do :P)
> I could believe that most of these changes may require some rework of
> some parts of layout and frame construction (I'm looking at float /
> out-of-flows / first-letters, etc), but I also think some of those are
> the ones where the frame constructor handles dynamic changes poorly
> (ib-splits certainly enter in this category, though I'm not sure that we
> mutate those during reflow).
> Anyway I could believe that if we refactor things with this in mind we
> could make frame construction better for dynamic changes.
> There are also a few CreateContinuationFor calls in block layout that
> could also be hard to replace, haven't checked in detail yet...
> Anyway, just wanted to know if other people think this goal would be
> reasonable / worth it.
> Thanks in advance,
>  -- Emilio
> [1]:
dev-tech-layout mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: Mutating the frame tree shape from reflow code.

Robert O'Callahan-3
You would need to design a completely different approach to handle vertical
and horizontal breaking. I agree the current approach has severe problems
but even just designing something significantly better is not easy ... and
actually switching Gecko to it would be a mountain of work.

Maybe you should get really good break-handling into Servo layout and then
import Servo layout into Gecko a la Stylo ("Layo"?).

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
dev-tech-layout mailing list
[hidden email]