xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Finn Bock <bck...@worldonline.dk>
Subject Re: Performance improvement in property consumption.
Date Wed, 13 Oct 2004 15:08:45 GMT
[Glen]

>>All fo elements are required to
>>extract all the
>>properties that they need and to store the values as
>>instance fields in
>>the fo element.
>>
> 
> 
> I love the performance boost you're recording but have
> a philosophical issue of an "fo object needing a
> property"--it is really an issue of the
> *FOEventHandler subclass* that needs the
> properties--and some handlers need/implement more
> properties than others.

Does any event handler need more or different properties than what is 
defined in the spec under each fo element? Because that is the set of 
properties that I store in the fo objects.

If further properties are needed by any property consumer, it can just 
be added to the fo element. An example could be "text-decoration" on 
fo:block.

> So if we did this at the FO level, in effect, we'd
> have to (1) store an instance variable of every valid
> property for each FO, given that we wouldn't know
> whether the FOEventHandler's needs it beforehand, and

Yes. Which is massively more efficient than storing the exact same 
properties in a PropertyList.

> (2) instead of the programmatic convenience of
> getPropString(PR_OFFICIAL_PROPERTY_NAME), we'd have to
> remember what each of the properties are named in the
> FO's (We can probably standardize these though.)  

I've consistly picked getOfficielPropertyName() as the name of the 
getter method.

> Another clarification needed:  when would the property
> list's memory get released--at the PageSequence level,
> or as soon as the FO is finished?  

At the endElement() event.

> Because the values
> of some FO's properties further downstream depend on
> an earlier FO's properties, we may not be able to
> release the memory when the earlier FO is finished. 

If a property value is needed by a following sibling, then it can be 
found as an instance field on the fo object that defined the property.

> Or, (to support inheritance) we may need to store
> instance variables for what may be a very unlikely
> event of a child needing that value.

I don't understand what you mean. All property inheritence is resolved 
at the time of the child startElement() event. The resolution is done 
using the parent propertylist while it still exists.

> Also, are there any other options for releasing this
> memory that you know of? Is there someway this .bind()
> or other releasing of memory can be done within the
> FOEventHandler subclasses, or at least within
> LayoutManager (forgetting about RTF) instead?  

I don't see any benefit at all, from such approaches.

PS. The description of releasing property list only apply to normal 
elements. All element under fo:marker are treated differently.

regards,
finn

Mime
View raw message