On 9/11/13 9:12 AM, Boris Zbarsky wrote:
Or bail out of it, either way. For the use cases here bailing out would be better, since people tend to do this sort of thing in a loop.
Yes. But ideally it would be nice to be able to resume layout where you left off. According to the bug, Chrome's implementation doesn't do this and requires layout to be restarted the next time around. This would regress performance in the case in which script queries `offsetWidth` and then the unchanged page is laid out for rendering, since two layouts (one partial, one full) must be done.
I think solving this the right way (i.e. in a way that doesn't regress perf for the above case) is much easier in a multithreaded architecture like Servo than in a single-threaded architecture like Blink's, since suspending the state of the layout task is easy. The tricky bit is just being able to bail out of layout at any point. We discussed this yesterday and it may not actually be that hard to do on a coarse-grained level: just insert a potential bailout point after each traversal.
But again, the hard part is knowing when you have a final value for the thing of interest.
Well, the easiest, but imprecise, thing to do would be to send the message after the node is visited during the final assign-heights traversal. No more layout computation happens for each node at that point. (This final traversal roughly corresponds to `FinishAndStoreOverflow()` in Gecko AIUI, though I'm not intimately familiar with Gecko's reflow algorithm.) Of course this is very conservative, but it could still avoid performing assign-heights (which is where shaping is performed) for nodes later in the document than the node of interest.
Patrick _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
