From: Martin Sevior (msevior@physics.unimelb.edu.au)
Date: Mon Jul 29 2002 - 10:29:07 EDT
On Mon, 2002-07-29 at 23:47, Tomas Frydrych wrote:
>
> The updateBackgroundColor mechanism seems to be very seriously
> flawed and needs to be rewritten, as it is one of the main bottlenecks
> in the code.
>
I agree.
> The problem is this: the various calls to updateBackgroundColor()
> propagate down to the run level, where
> fp_Run::updateBackgroundColor() querries the PieceTable (!!!) for
> the background colour property.
This is certainly a mistake. I don't know how this happenned. It should
actually see if it's background colour property is set, if not it should
recursively query higher level containers until it finds a value or the
topmost container is reached. I was just talking about this with Marc.
This is not the way it should be --
> *the only* place the runs should ever querry the PT for properties is
> ::lookupProperties() which in turn is only to be called in response to
> formatting changes in the PT.
>
Agreed.
> If the background colour needs to change because the PT has
> changed, then let it be done in ::_lookupProperties; if the PT has not
> changed, then the updateBackground colour has no business of
> querring the PT. So my question is why do we need
> updateBackground() colour at all?
>
We probabally don't. Ahh now maybe we do for "non-printable" background
colour. We can set the screen color via preference. This screen color is
not printed and is not stored in the document. We might have needed
updateBackground color to get this right upon a screen color preference
change. However I'm fairly sure we don't need to do it this way.
Cheers
Martin
This archive was generated by hypermail 2.1.4 : Mon Jul 29 2002 - 10:20:48 EDT