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? 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. Vincent
