You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Victor Mote <vi...@outfitr.com> on 2003/11/19 20:04:45 UTC
ANN: alt-design can now be integrated??
ANNOUNCEMENT: I have just committed a change that 1) allows LayoutStrategy
to tell whether an FO Tree should be built, 2) has Driver act on this, i.e.
to build an FO Tree only if LayoutStrategy indicates that this should be
done. This should theoretically allow Peter's logic to be used as a
LayoutStrategy within the trunk development line. What I have done is
probably overly simplistic, but I will allow Peter or anyone wishing to work
on that strategy tell us what additional things are needed to accommodate.
To start integrating, create a subclass of LayoutStrategy, override the
foTreeNeeded() method to return false, then write a format() method that
does the layout work. LayoutStrategy knows its parent Document, which knows
its parent Driver, so you should be able to get to all of the parsing
variables that are needed. Let me know if you need help.
Since configuration is still messed up, you will need to hard-code a change
to Driver to get your new LayoutStrategy object created.
Victor Mote
Re: ANN: alt-design can now be integrated??
Posted by "Peter B. West" <pb...@powerup.com.au>.
John Austin wrote:
> On Wed, 2003-11-19 at 15:34, Victor Mote wrote:
>
>
> Geez! I was thinking more along the lines of plugging in a few new data
> structures for property lookup. I am exploring the old implementation
> through the marvel of code grooming in order to understand it.
>
> Don't worry, I have the time to do this right.
>
> I got a tiny improvement by playing around in some of PropertyList and
> PropertyListBuilder. This is just a throw-away effort of course. I did
> enough tracing this a.m. to realize that my 'linear behaviour' may
> be deeply buried. I have done this often enough that I don't
> expect more than marginal improvements from grooming/tweaking
> lines of code. [Gone are the days of PL/I and unaligned bit
> fields.]
>
> Before I found out about Alt-Design, I was thinking about using a
> HashMap with property names as keys and a class implementing
> some stack behaviour. Each new FO would conceptually 'push'
> new values on a stack for each property in it's list. A smart
> 'pop' would allow the entire set of properties for a FO to
> be popped together. Hopefully, this design would allow faster
> access to the current properties, without a need to search through
> higher 'activation records', 'stack frames', contexts or whatever
> you choose to call them.
I initially looked at a stack based approach. It seems natural enough,
given the nature of (most) inheritance. As I went along, I gradually
abandoned more and more of it, and finally realised that there was
nothing worthwhile left. I posted an epitaph to my stacks at this point.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
RE: ANN: alt-design can now be integrated??
Posted by Victor Mote <vi...@outfitr.com>.
John Austin wrote:
> On Wed, 2003-11-19 at 15:34, Victor Mote wrote:
> > ANNOUNCEMENT: I have just committed a change that 1) allows
> LayoutStrategy
> > to tell whether an FO Tree should be built, 2) has Driver act
> on this, i.e.
> > to build an FO Tree only if LayoutStrategy indicates that this should be
> > done. This should theoretically allow Peter's logic to be used as a
> > LayoutStrategy within the trunk development line. What I have done is
> > probably overly simplistic, but I will allow Peter or anyone
> wishing to work
> > on that strategy tell us what additional things are needed to
> accommodate.
> > To start integrating, create a subclass of LayoutStrategy, override the
> > foTreeNeeded() method to return false, then write a format() method that
> > does the layout work. LayoutStrategy knows its parent Document,
> which knows
> > its parent Driver, so you should be able to get to all of the parsing
> > variables that are needed. Let me know if you need help.
> >
> > Since configuration is still messed up, you will need to
> hard-code a change
> > to Driver to get your new LayoutStrategy object created.
> >
> > Victor Mote
>
> Geez! I was thinking more along the lines of plugging in a few new data
> structures for property lookup. I am exploring the old implementation
> through the marvel of code grooming in order to understand it.
This is not directly related to what you are doing. I realized in one of my
responses to Peter yesterday that it would be easier for me to go ahead and
implement the FO-Tree-less LayoutStrategy than it was to explain its
theoretical possibility (again). This is an attempt to make it easier for
Peter to integrate his work. If it helps you, good. If not, at least I don't
think it will hurt.
> Don't worry, I have the time to do this right.
>
> I got a tiny improvement by playing around in some of PropertyList and
> PropertyListBuilder. This is just a throw-away effort of course. I did
> enough tracing this a.m. to realize that my 'linear behaviour' may
> be deeply buried. I have done this often enough that I don't
> expect more than marginal improvements from grooming/tweaking
> lines of code. [Gone are the days of PL/I and unaligned bit
> fields.]
>
> Before I found out about Alt-Design, I was thinking about using a
> HashMap with property names as keys and a class implementing
> some stack behaviour. Each new FO would conceptually 'push'
> new values on a stack for each property in it's list. A smart
> 'pop' would allow the entire set of properties for a FO to
> be popped together. Hopefully, this design would allow faster
> access to the current properties, without a need to search through
> higher 'activation records', 'stack frames', contexts or whatever
> you choose to call them.
>
> The observations of performance indicate that there are millions of
> accesses through PropertyList.get(String propertyName) which are
> sent one-to-one through PropertyList.get( propertyName, true, true)
> and thence on to PropertyList.findProperty( propertyName, true ).
>
> Combine this information with the fact that I didn't notice the
> performance of the corresponding put() operations on the HashMap
> underneath PropertyList to conclude that retrieval is much more
> intensive than storage in this structure.
>
> So I should optimize retrievals.
That certainly sounds right to me.
> My plan is to get to know the internals of FOP that are 'in contact
> with' the existing code, then get to know the Alt-Design, then play with
> more and more of it until I feel comfortable integrating it.
>
> I don't expect fast-track to committer status, I would hope to work
> with one or two current participants and package the changes so that
> they 'drop in' to place. (We'll see)
We're glad to have you involved here.
Victor Mote
Re: ANN: alt-design can now be integrated??
Posted by John Austin <jw...@sympatico.ca>.
On Wed, 2003-11-19 at 15:34, Victor Mote wrote:
> ANNOUNCEMENT: I have just committed a change that 1) allows LayoutStrategy
> to tell whether an FO Tree should be built, 2) has Driver act on this, i.e.
> to build an FO Tree only if LayoutStrategy indicates that this should be
> done. This should theoretically allow Peter's logic to be used as a
> LayoutStrategy within the trunk development line. What I have done is
> probably overly simplistic, but I will allow Peter or anyone wishing to work
> on that strategy tell us what additional things are needed to accommodate.
> To start integrating, create a subclass of LayoutStrategy, override the
> foTreeNeeded() method to return false, then write a format() method that
> does the layout work. LayoutStrategy knows its parent Document, which knows
> its parent Driver, so you should be able to get to all of the parsing
> variables that are needed. Let me know if you need help.
>
> Since configuration is still messed up, you will need to hard-code a change
> to Driver to get your new LayoutStrategy object created.
>
> Victor Mote
Geez! I was thinking more along the lines of plugging in a few new data
structures for property lookup. I am exploring the old implementation
through the marvel of code grooming in order to understand it.
Don't worry, I have the time to do this right.
I got a tiny improvement by playing around in some of PropertyList and
PropertyListBuilder. This is just a throw-away effort of course. I did
enough tracing this a.m. to realize that my 'linear behaviour' may
be deeply buried. I have done this often enough that I don't
expect more than marginal improvements from grooming/tweaking
lines of code. [Gone are the days of PL/I and unaligned bit
fields.]
Before I found out about Alt-Design, I was thinking about using a
HashMap with property names as keys and a class implementing
some stack behaviour. Each new FO would conceptually 'push'
new values on a stack for each property in it's list. A smart
'pop' would allow the entire set of properties for a FO to
be popped together. Hopefully, this design would allow faster
access to the current properties, without a need to search through
higher 'activation records', 'stack frames', contexts or whatever
you choose to call them.
The observations of performance indicate that there are millions of
accesses through PropertyList.get(String propertyName) which are
sent one-to-one through PropertyList.get( propertyName, true, true)
and thence on to PropertyList.findProperty( propertyName, true ).
Combine this information with the fact that I didn't notice the
performance of the corresponding put() operations on the HashMap
underneath PropertyList to conclude that retrieval is much more
intensive than storage in this structure.
So I should optimize retrievals.
My plan is to get to know the internals of FOP that are 'in contact
with' the existing code, then get to know the Alt-Design, then play with
more and more of it until I feel comfortable integrating it.
I don't expect fast-track to committer status, I would hope to work
with one or two current participants and package the changes so that
they 'drop in' to place. (We'll see)
--
John Austin <jw...@sympatico.ca>