[webkit-dev] Two Pass Layout?

[Roland Steiner]

On Sat, Sep 19, 2009 at 12:42 AM, Alex Milowski <alex at milowski.org> wrote:

> On Thu, Sep 17, 2009 at 11:36 PM, Roland Steiner
> <rolandsteiner at google.com> wrote:
> > Hi Alex,
> > I'm in the process of doing ruby layout, currently under review
> (reviewers:
> > *hint, hint*), where I had several of the same issues, albeit not quite
> as
> > severe as with MathML (in effect, one could see ruby as nothing than a
> > series of <mover>/<munder> operations).
>
> Is there a patch I can take a peek at?


sure: https://bugs.webkit.org/show_bug.cgi?id=28420

Compared with MathML I'm sure it's rather simple (simplistic? ;) ), though.


> Well, to some extent the way glyph stacking works is you pick a certain
> font size in pixels.  You then stack the glyphs by determining how many
> of that size you need to fill a certain pixel height.  Then zooming/etc.
> all
> seem to work well afterwards.  Oddly, for stretchy operators, the current
> font size isn't much of a consideration because you are building a large
> glyph out of smaller glyphs.


yes, but having, e.g. matrices

( a )

and (excuse the bad ASCII art)

/   \
| a |
| a |
| a |
\   /

would probably require different font sizes for the small vs. the stacked
brackets (I presume).


>  > Also note that the DOM may be manipulated afterwards - nodes added or
> > removed, causing recalculations or even add/remove line breaks (so you
> need
> > to be careful when caching values).
> > As for calulations, adding special anonymous boxes to group stuff into
> > smaller chunks might help (not sure there is actually a need for such
> things
> > in MathML). OTOH, such boxes also adds complexity when it comes to DOM
> > manipulation.
>
> Very true.  I haven't looked into how the rendering interacts with DOM
> changes.
> I assume, as some point, layout calls will be needed again.  In this case,
> I'd need to know when the siblings change size.  Is there some event that
> gets propagated for that kind of thing that turns into a sequence of method
> calls for notification?
>

I think it should be sufficient if you simply override the addChild() and
removeChild() methods in your renderer and fire off those recalculations. No
need to explicitly call layouting on your part, AFAICT.


> > Not sure I understand the requirements correctly, but can't you just nuke
> > the line boxes with deleteLineBoxTree() and have them rebuilt?
>
> I'll have to try that and see what happens.  The part I don't get rendering
> is how nested replaced objects seem to get treated different.  That is,
> if I call layout() twice with online inline content (and so a sequence of
> regular line boxes), bad things happen.  If I call layout() twice with
> a nested mfenced (an inline-block and so replaced content), the right
> thing happens.  If I call layout() twice with a nested mtable, bad things
> happen.
>
>
Not sure, what "bad things" are, but I'd just try and call
 deleteLineBoxTree() before the 2nd call as an experiment and see whether
that improves things (unless you need those line boxes).

However, overloading layout() itself and to the 2-passes in there "by hand"
(or by calling the base version at an appropriate time in between, which I
agree is prudent*) would seem to be a cleaner solution IMHO, rather than
calling it twice. This would also give you better control when doing
horizontal stacking vs. vertical stacking.

*) calling the base version at some point is prudent insofar as that it does
*something* when the user gets fancy and, e.g., tries to float or position
your math objects (OTOH, I guess you could also completely suppress such
styles for MathML).


Cheers,

Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090924/f4e8c48e/attachment.html>