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

From: Joaquin Cuenca Abela (
Date: Tue Jul 30 2002 - 03:18:38 EDT

  • Next message: Martin Sevior: "Re: commit head: improve fp_Run::updateBackgroundColor()"

    --- Tomas Frydrych <> wrote:
    > I have made changes to the UT_RGBcolor class, so
    > that it can
    > represent a transparent colour -- I have taken the
    > approach
    > suggested by Joaquin with an extra bool, because it
    > makes it
    > possible to create a transparent colour that
    > otherwise appears to be
    > white and that way we do not need to modify the
    > graphics classes to
    > draw white bacground when the colour is set to
    > transparent.

    I've not yet look at your commit, but I was not
    suggesting to add a bool to UT_RGBColor, but to

    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

    Just add a single boolean to fp_Run to say that its
    background is transparent.

    I updated yesterday to current cvs, and I had some

    1) Gtk+ 2: As you may know, gtk+ 2 depends on Xft...
    1, and we use Xft2. That means that if you try to
    compile with --enable-xft, you end linking with Xft1
    and Xft2, which is a very bad idea. So say hello to
    the new antialiasing in the menu items, say goodbye to
    the antialiasing in the main canvas.

    This conflictive linking sometimes work (it worked for
    me in little programs), but yesterday xft enabled
    abiword was not even starting. AbiWord was finding
    its fonts, but pango was not finding any available
    font (when gtk+2 apps that don't link with xft2 works

    Maybe it's just a problem with my config, but in
    general if someone makes it startup, you should not
    hope for anything stable.

    The only possible solution is copy to Xft in our cvs
    and rename it. At least now I have a real motivation
    to do it :)

    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 (?)

    At this point, I had better things to do, like sleep.
    I didn't had the time to study where was the problem,
    I will investigate it this evening.


    Joaquin Cuenca Abela

    Do You Yahoo!?
    Sign up for SBC Yahoo! Dial - First Month Free

    This archive was generated by hypermail 2.1.4 : Tue Jul 30 2002 - 03:25:30 EDT