On 6/4/13 9:47 PM, Patrick Walton wrote:
We're trying to figure out what to do when an inline RenderBox of an
inline flow becomes non-inline. This is a vexing issue, as it violates
the invariant that a flow's descendants and the flow itself are the only
flows that need to be reconstructed from scratch when a box's style
changes.
This invariant simply isn't. ;) Consider this simple testcase:
<div>
<span style="display: table-cell">Some</span>
<div id="willChange">text</div>
<span style="display: table-cell">here</span>
</div>
and then toggling the display of the id="willChange" div to
"table-cell". Or to "none", for that matter.
I'm wondering if any layout gurus have any advice as to what to do here.
What is the most elegant way to handle this case? Is there anything we
should be aware of in order to optimize this path?
So first off, this is usually a rare case. So in practice, I believe
the Gecko approach of "wipe out part of the render tree and recreate it"
is perfectly reasonable here as a complexity/performance tradeoff.
The one situation in which we need to be careful, I think, is when a
block is appended to an inline during parsing. Right now Gecko will
rebuild the render subtree for that parent inline if this is its first
block child and do an in-place append otherwise.
That said, if splitting and combining stuff in place does not have
unreasonable complexity overhead it may be faster than reconstructing.
Depending on how complicated it gets: note that reconstructing may be
easier to parallelize than in-place fixup...
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
