Re: updateBackgroundColor mechanism is badly flawed

From: Martin Sevior (
Date: Mon Jul 29 2002 - 10:29:07 EDT

  • Next message: Joaquin Cuenca Abela: "Re: updateBackgroundColor mechanism is badly flawed"

    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.


    > 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.



    This archive was generated by hypermail 2.1.4 : Mon Jul 29 2002 - 10:20:48 EDT