On 26.11.2007 16:30:31 Vincent Hennebert wrote:
> Hi,
> 
> A bit late, but still...
> 
> Jeremias Maerki wrote:
> > As you probably noticed, I'm looking again into improving the
> > performance of the intermediate format:
> > http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml
> 
> <snip what="IFPainter vs area Tree"/>
> 
> If I understand well, the intermediate format would be some kind of 
> abstract low-level page description format that would serve as a basis 
> for transformation into other (even more) low-level formats. That could 
> have been PDF as well, but XML is simpler and more straightforward to 
> manipulate thanks to well-defined APIs like SAX. I guess this is roughly 
> a matter of moving to a common earlier point the complexity that is 
> currently duplicated in each renderer. Did I get the picture right?

Yes

> I second Adrian in saying that I like this approach which looks quite 
> elegant to me. Even if that would probably be good to cleanup the area 
> tree code a bit, which would have occured with the 2nd approach, I like 
> this one and would probably vote for it.
> 
> 
> > In contrast to the above, there's an additional way to increase
> > performance without much work:
> > We just make use of modern multi-core CPUs. FOP is mostly
> > single-threaded. If you look at the CPU usage in a dual-core machine,
> > you'll see that it will stay at about 50% when rendering. If we do area
> > tree parsing in the main thread and rendering in another we can do both
> > at the same time. That's an easy way to decouple the two tasks.
> 
> I don’t have the same concerns as Chris but I also don’t think it’s 
> a good idea. I believe the code base simply isn’t clean enough to switch 
> to multi-threading. I think we will run into synchronisation issue that 
> will be a real nightmare to solve.
> Although I do think several threads would make sense from a software 
> architecture point of vue, but we are no near ready to it IMHO. That 
> might indeed change once we upgrade the minimal compliance to Java 1.5 
> and its java.util.concurrent library.

Ok, that idea is postponed in that case, although it might itch me one
rainy sunday. ;-)


Jeremias Maerki

Reply via email to