Re: remove Runnable from PageSequenceLayoutManager?

2004-12-15 Thread Simon Pepping
On Tue, Dec 14, 2004 at 04:39:20PM -0800, Glen Mazza wrote:
 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?

It is true that nothing has been done to make threading a reality. I
do not object to your removing the Runnable interface.

Are you a fan of Extreme Programming? They seem to teach you to avoid
adding future features.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl



remove Runnable from PageSequenceLayoutManager?

2004-12-14 Thread Glen Mazza
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