One thing I'm missing here, for Finn's design below:
values = null // always null. values = reference to a 'foo' Property instance values = reference to a 'baz' Property instance
Can't we just have, say, values refer to the parent's Property instance in cases where inheritance is applicable?
I.e., for all those references to the 'foo' property instance for the children of an FO where that value would be inherited, we don't have to create a new Property instance, just a reference to the inherited instance.
Right, that is also the way I see it.
But if the problem is the *recursion* necessary to determine the property instance to inherit--here, not the memory problem, but processing speed--I'm thinking of a PropertyWindow instance as follows:
A PropertyWindow would be used temporarily during FObj
property initialization to hold references to all the
property instances that would be relevant for that
FObj should a property not be explicitly defined. So, to populate the property instances for a
particular FObj, i.e., the "values" array:
Pardon me for repeating what might be obvious, but I'll like to take a look at what information we want to store at each FObj. I can come up with 3 different strategies:
1) Only store the specified properties. That is what HEAD does now. 2) Put the relevant properties in a fast Property array and the remaining specified properties in a HashMap. For fo:root the result would be an array of size 1 for the 'media-usage' property. 3) Expect to store every valid property. For fo:root that would mean allocating an array large enough to store every defined property. This is what my patch does, and the "values" array works as the PropertyWindow.
As I understand your PropertyWindow proposal, it would allow us to implement no. 2) above. I'll try to come up with some numbers to see how much memory that would use/save compared to 1) and 3).
Alt-design (trying the hyphen for a while) takes different approaches at different times. While building the subtree of any node, all of the properties are maintained in a HashMap, along with a BitSet of specified properties.
When the subtree construction is complete, the HashMap and BitSet are used to build the sparse array of only the relevant *resolved* property values (not properties - one of the differences with HEAD) and then thrown away.
This approach has to be modified in two environments - fo:static-content and fo:marker. In the case of fo:marker, the inherited environment is not known at parse time, and in the case of static-content, the appropriate fo:retrieve-marker subtrees are not know until the region-body area tree is constructed.
In general, the impact on storage of maintaining full details for fo:static-content and fo:marker will not be huge, even if these are parsed as encountered. However, the plan for alt-design is 1) not the parse an fo:marker subtree unless and until it is required, and 2) to re-parse fo:static-content for each page after the region-body area tree has been constructed. (I'm working on these modifications now.)
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>