Team, PageSequenceLayoutManager implements Runnable, theoretically to allow for the layout of each page sequence on separate threads. The more complex logical aspects needed for this to happen (e.g., idref resolution, page numbering) though are not implemented, rendering this feature not very useful. We're not using Runnable now, and so I'd like to yank it before the upcoming release--it is easy to place it back in later if we do this in the future releases (although the more extensive logic will still need to be developed). Thoughts? Objections?
I don't see multithreading page-sequence layouts as a certainty ATM because: (1) multithreading may not be workable/worthwhile given the layout process and the dependences of one page sequence upon another (2) multithreading may not buy us anything performance-wise: instead of: F-PS1 --> L-PS1 --> F-PS2 --> L-PS2 --> F-PS3 --> L-PS3 (Where F-PS1 means "create FO Tree for page sequence 1" and L-PS1 means "layout page sequence 1", etc.) Multithreading might mean: F-PS1 --> (F-PS2, L-PS1) --> (F-PS3, L-PS1, L-PS2) --> (L-PS2, L-PS3) But cycles spent on getting F-PS2 done earlier (i.e., before L-PS1 is finished) end up slowing down L-PS1 by an equivalent rate, and because of context switching, performance would appear to be actually worse. (3) whether we have the multithreading at the wrong level--i.e., normally, it would appear that the SW that embeds FOP would do the multithreading (i.e., a servlet which runs multiple FOP reports, one for each thread), not FOP itself. Having dual levels of multithreading appear suspect to me--I doubt Xalan goes that route. Thanks, Glen
