RE: FOP ~ PropertyList search gives linear performance (FROM: fop-user)

[Victor Mote <vi...@outfitr.com>]

Peter B. West wrote:

[This message was originally on fop-user. I have moved it here as it is
mostly a dev topic.]

> The approach I took was to resolve all of the properties at every node
> in the tree during the parsing.  As the FO tree builder descends to the
> leaf nodes, a complete properties array is maintained at each level.
> Before the tree builder exits a node though, all properties not relevant
> to that particular node type are discarded (i.e. the property sets are
> "reduced") so that the maximal data arrays are short-lived.  The
> relevant properties are maintained in sparse arrays.

FWIW, we now have the FO Tree tied together in a more tree-like way. We have
several methods which rely on going up the tree to an appropriate level to
get information. Right now, that is mostly high-level stuff like the logger
& document-level information. For properties, I recommend that we use
appropriately-named "get" methods for each individual property. Then we can
hide the data structures behind that & modify them as needed. So if a "get"
method sees that the property is inherited, it can get it from the parent
node instead of needing to walk through the tree to resolve the value.

> There is a flaw in this approach which is exposed when markers are
> processed.  Because marker subtrees are conceptually "re-parented" in
> the static-content tree of the page on which they are laid out, the
> properties within the marker tree cannot initially be resolved, and the
> properties of the static-content trees cannot be "reduced".  This
> situation is not catered for in the existing code, but is quite easy to
> accommodate by not reducing the property sets of nodes in the
> static-content, and by slicing the marker subtrees out and storing them
>   unresolved for later processing, including property resolution, in the
> context of static-content.
>
> All of this assumes that property resolution cannot be completed
> independently of layout.  This is a major point of difference between me
> and everyone else on the FOP team, but the implication is there in the
> Rec. if you read it carefully.

I think I agree with your statement that "property resolution cannot be
completed independently of layout" for the specific case that you mention. I
think where we differ is about whether the FO Tree can simply store a "To Be
Determined At Layout" value and go on about life, or whether the concept of
the FO Tree should be scrapped entirely because of this issue.

Victor Mote