Uri Bernstein (Google) Reporter
	Description • 19 years ago

This is a follow-up on bug 319930 and bug 329878.

Very large bidi plaintext files (e.g. attachment 205680 [details] on bug 319930) still take about 13-15 times longer to render than non-bidi files of the same size (e.g., the same file in Latin-1 or EUC-JP).

On my machine (iMac G5 1.8Ghz), this file currently (after fixing bug 319930 and  bug 329878) takes 72 seconds to render. In Latin-1 encoding, the same file takes about 5.5 seconds.

A current profiling report (after fixing these two bugs) can be found in attachment 214707 [details] (bug 329878 comment 9).

A suspected reason for the slowness is that in the bidi case it seems like the entire existing part of the document is reflowed for each incremental reflow. Normally only the last line of the <pre> and maybe the one before that would be marked dirty and reflowed. Fixing bug 263359 might help resolving this.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 19 years ago

OK, so what's happening here is that we hit the code at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsBlockFrame.cpp&rev=3.758&mark=790-799#785 and that of course kills any hopes of decent perf that we might have had.

So it seems to me that what bidi _really_ wants here is to dirty just the lines that contain frames whose continuations got messed with, right?

Do we have any sane way of doing that?

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 19 years ago

I should also note that _inserting_ bidi continuations (via CreateBidiContinuation) already marks relevant lines dirty.  So it's just RemoveBidiContinuation() that needs to do dirtying, and then we can remove this "force reflow" stuff.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 3 • 19 years ago

It should be pretty easy to call ReflowDirtyChild on the right frames.

I'm not pleased with the performance of ReflowDirtyChild, however, so it could become a new bottleneck. But if so, that sounds like a post-reflow-branch issue.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 19 years ago

Calling ReflowDirtyChild will post another reflow command, from inside reflow.  We don't really want that....  Post-reflow-branch that might be easier, of course.

	Boris Zbarsky [:bzbarsky]
	Comment 5 • 19 years ago

OK, with bug 330373 it looks like we're marking lots of lines dirty because our run lengths are smaller than the fragment lengths (so we're calling EnsureBidiContinuation and then dirtying the line).

Could we perhaps have EnsureBidiContinuation output whether something's changed?  Or something like that?  That is, do we always have to dirty the line here?  Note that I'm not sure why bug 329878 actually happened.  That is, why did the in-flows need to be removed in that case?