xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Re: Concerning markers & rebinding properties
Date Wed, 07 Jun 2006 12:58:49 GMT
On Jun 7, 2006, at 09:42, Jeremias Maerki wrote:

> It would be interesting to know how much time is effectively lost  
> if the
> properties are re-evaluated unconditionally.

As I indicated, it may not be much. The properties package already  
contains a lot of optimizations, and I guess it depends a bit on what  
is Rule and Exception here. In the current state, a property not  
being re-evaluated is the exception to the rule. I'll have to browse  
a bit through the Rec to see whether this reflects the prescriptions...

> However, I agree with you
> that it is certainly possible to skip reevaluation for many  
> properties.
> And if it's easily possible it should be done. The "cloned"  
> indicator on
> the FO sounds like a pretty simple and suitable solution.
> Or are there better ones?

I've considered a few, but I think the suggested approach has the  
benefit that it allows to settle these matters gradually. I can add  
the switch now, flip it in FObj.clone(), and use it in TableCell.bind 
(). Other FOs / Properties can be altered to use it at a later time,  
or never for that matter.

I've also considered pulling the check to the properties' side --as  
in: FObj.bind() keeps making unconditional calls to PropertyList.get 
(), and the latter sorts out whether the FO was cloned.
That would expose the 'cloned' switch one way or the other --adding  
yet another public accessor is probably the easiest way to go about  
that, but I somehow don't like this (unless that access would, for  
example, come in handy for the layoutengine or other packages)


Andreas


Mime
View raw message