Bug 216418 has some pathological testcases with extremely many inline wrapper frames, which we spin our wheels allocating, reflowing, and fragmenting. These are all unstyled, they all have the same bounds, fragmentation, etc. If we're careful, we could probably get away with just using one nsInlineFrame for the whole stack, or something to that effect. It looks like Chrome is doing something along those lines -- they appear to be doing some sort of optimization to coalesce or ignore all of these inline wrappers. At least: comparing these two testcase in Chrome... https://bugzilla.mozilla.org/attachment.cgi?id=9333233 https://bugzilla.mozilla.org/attachment.cgi?id=9333234 ...shows a substantial performance difference (10-50ms for the first vs. 700-1500ms for the second), though the only difference in the markup is that there's a non-functional `margin-top` styling on the inline elements in the second testcase, which I imagine is defeating Chrome's optimization. We may want to consider implementing a similar optimization so that we can achieve similar trivial rendering times for the first testcase here. The original real-world testcase on bug 216418 has a whole bunch of accidental levels of inline-element nesting, with unstyled inline-level wrapper elements, due to having a bunch of stuff like `From <foo@example.com>` in the source. Each `<foo@example.com>` expression is interpreted as an unrecognized HTML element, and adds a level of nesting.
Bug 1833208 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Bug 216418 has some pathological testcases with extremely many inline wrapper frames, which we spin our wheels allocating, reflowing, and fragmenting. These are all unstyled, so (given that they're wrapping the same content) they all have the same bounds, fragmentation boundaries, etc. If we're careful, we could probably get away with just using one nsInlineFrame for the whole stack, or something to that effect. It looks like Chrome is doing something along those lines -- they appear to be doing some sort of optimization to coalesce or ignore all of these inline wrappers. At least: comparing these two testcase in Chrome... https://bugzilla.mozilla.org/attachment.cgi?id=9333233 https://bugzilla.mozilla.org/attachment.cgi?id=9333234 ...shows a substantial performance difference (10-50ms for the first vs. 700-1500ms for the second), though the only difference in the markup is that there's a non-functional `margin-top` styling on the inline elements in the second testcase, which I imagine is defeating Chrome's optimization. We may want to consider implementing a similar optimization so that we can achieve similar trivial rendering times for the first testcase here. The original real-world testcase on bug 216418 has a whole bunch of accidental levels of inline-element nesting, with unstyled inline-level wrapper elements, due to having a bunch of stuff like `From <foo@example.com>` in the source. Each `<foo@example.com>` expression is interpreted as an unrecognized HTML element, and adds a level of nesting.
Bug 216418 has some pathological testcases with extremely many inline wrapper frames, which we spin our wheels allocating, reflowing, and fragmenting. These are all unstyled, so (given that they're wrapping the same content) they all have the same bounds, fragmentation boundaries, etc. If we're careful, we could probably get away with just using one nsInlineFrame for the whole of elements, or something to that effect. It looks like Chrome is doing something along those lines -- they appear to be doing some sort of optimization to coalesce or ignore all of these inline wrappers. At least: comparing these two testcase in Chrome... https://bugzilla.mozilla.org/attachment.cgi?id=9333233 https://bugzilla.mozilla.org/attachment.cgi?id=9333234 ...shows a substantial performance difference (10-50ms for the first vs. 700-1500ms for the second), though the only difference in the markup is that there's a non-functional `margin-top` styling on the inline elements in the second testcase, which I imagine is defeating Chrome's optimization. We may want to consider implementing a similar optimization so that we can achieve similar trivial rendering times for the first testcase here. The original real-world testcase on bug 216418 has a whole bunch of accidental levels of inline-element nesting, with unstyled inline-level wrapper elements, due to having a bunch of stuff like `From <foo@example.com>` in the source. Each `<foo@example.com>` expression is interpreted as an unrecognized HTML element, and adds a level of nesting.
Bug 216418 has some pathological testcases with extremely many inline wrapper frames, which we spin our wheels allocating, reflowing, and fragmenting. These are all unstyled, so (given that they're wrapping the same content) they all have the same bounds, fragmentation boundaries, etc. If we're careful, we could probably get away with just using one shared nsInlineFrame for the whole stack of elements, or something to that effect. It looks like Chrome is doing something along those lines -- they appear to be doing some sort of optimization to coalesce or ignore all of these inline wrappers. At least: comparing these two testcase in Chrome... https://bugzilla.mozilla.org/attachment.cgi?id=9333233 https://bugzilla.mozilla.org/attachment.cgi?id=9333234 ...shows a substantial performance difference (10-50ms for the first vs. 700-1500ms for the second), though the only difference in the markup is that there's a non-functional `margin-top` styling on the inline elements in the second testcase, which I imagine is defeating Chrome's optimization. We may want to consider implementing a similar optimization so that we can achieve similar trivial rendering times for the first testcase here. The original real-world testcase on bug 216418 has a whole bunch of accidental levels of inline-element nesting, with unstyled inline-level wrapper elements, due to having a bunch of stuff like `From <foo@example.com>` in the source. Each `<foo@example.com>` expression is interpreted as an unrecognized HTML element, and adds a level of nesting.