Re: commit head: improve fp_Run::updateBackgroundColor()

From: Tomas Frydrych (
Date: Tue Jul 30 2002 - 04:17:33 EDT

  • Next message: Joaquin Cuenca Abela: "Re: commit head: improve fp_Run::updateBackgroundColor()"

    > I've not yet look at your commit, but I was not
    > suggesting to add a bool to UT_RGBColor, but to
    > fp_Run.
    It would not work, the transparency is attribute of the colour, not of
    the run, and it has to be able to propagate down from the containers.

    > Basically, I wanted to keep UT_RGBColor a... RGB
    > color. As I said, we don't handle transparency all
    > over our code, so there is no need to change
    > UT_RGBColor.
    Anythings that lookups bgcolor property can be transparent ...

    > 1) Gtk+ 2: As you may know, gtk+ 2 depends on Xft...
    just for the record, I am currently not able to work under Linux (have
    not been for a while).

    > 2) Performance was *poor*. Very poor. It was taking
    > a bit more to open my doc (~3 minutes) than when we
    > first started with this performance course. I don't
    > know why it was so slow, but in the stats I had yet
    > one more time ::find_slot with >20 000 000 calls.
    > The "only" differences between my last build and this
    > one are:
    > 1) gtk+ 2 (I'm not suspecting this change)
    > 2) non Xft (neither this one, but who knows...)
    > 3) recent, non gtk+2 changes (?)
    > 4) my own local changed diffed from my old tree and
    > patched to the new one (?)

    I have done my profiling on win32, and at the last run pretty much all
    of the top functions in terms of time were those interfacing to system
    graphics calls -- font setting, width measuring, etc. So I would not be
    surprised if the gtk2 has something to do with it.


    This archive was generated by hypermail 2.1.4 : Tue Jul 30 2002 - 04:26:26 EDT