Open Bug 193212 Opened 17 years ago Updated 10 years ago
Only use CJK line breaker algorithm for CJK text
This is an idea I experimented with last year, but didn't find that it was much of a performance win for pageload. Now I want to investigate its impact on typing and editing performance, where PrepareUnicodeText() consumes a lot of time (see figures in bug 35296). I will resurrect my patch, unbitrot it and attach it here. The general strategy is to set a flag in nsGenericDOMDataNode.cpp when CJK (Chinese, Japanese or Korean) characters are present, and only use the CJK linebreaker in nsTextTransformer when this flag is present. Otherwise we will use a simpler linebreaker which will not have to scan for CJK characters internally.
Will this change make the code simpler? If not, could we add some refactoring in the process?
In principle, yes, but in the first instance I want to produce a simple-as-possible patch for use in performance profiling.
OS: All → Windows 2000
Hardware: All → PC
This patch has at least one serious bug: the nsWesternLineBreaker can end up being used even on CJK pages, because the first call to nsDocument::GetLineBreaker may be before the parser has encountered any CJK characters.
It seems to me that bug 255990 suggests pretty much the opposite (and makes more sense to me).
You need to log in before you can comment on or make changes to this bug.