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?

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.


Reply via email to