Optimize bidi [re-]resolution for long continuation chains
Categories
(Core :: Layout, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox134 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
nsBidiPresUtils::ResolveParagraph
may become terribly expensive when there are very long continuation chains involved, e.g. in bug 1925916.
As ResolveParagraph
passes through the text, it calls RemoveBidiContinuation
to clear any pre-existing non-fluid continuation that may be present when it reaches the end of a textframe but the direction run continues. Note, however, that RemoveBidiContinuation
is called here even if the next continuation is already fluid (i.e. not a bidi continuation). That seems unnecessary.
It wouldn't matter much, except that one of the things RemoveBidiContinuation
does is to make the next continuation non-fluid (and propagate this up through its inline ancestors).
But it's highly likely, in the case of a large amount of mostly-same-direction text, that the direction run will continue through the next line, and the next, etc. So the non-fluid continuation that RemoveBidiContinuation
just imposed will then be removed when we reach the end of the next textframe, and a new one set for the next line, and so on until the actual end of the direction run is reached.
All this isn't a problem during the initial bidi processing of a block, when we're doing bidi resolution and line-breaking for the first time; but it becomes really expensive when reflowing such a block, as ResolveParagraph
causes continuations to be made non-fluid and then revert to fluid again, rippling through a list of potentially thousands of lines.
I think we may be able to avoid this by making RemoveBidiContinuation
a no-op for the case where the continuation is already fluid.
Assignee | ||
Comment 1•10 months ago
|
||
Updated•10 months ago
|
Comment 2•10 months ago
|
||
From the try build, profile for the testcase in bug 1925916: https://share.firefox.dev/40pDeHw (between 3s-7s)
Comment 4•10 months ago
|
||
bugherder |
Updated•10 months ago
|
Description
•