Re: Sawfish building patch

John Harper <jsh unfactored org> writes:

> Federico Mena Quintero writes:
> |> Imlib still works better for sawfish than gdk-pixbuf does, so I don't
> |> want to remove the possibility of using it
> |
> |Why is this?  I'd like to fix any shortcomings in GdkPixbuf that make it
> |less preferable than Imlib.
> It's a combination of things:
> 1. Imlib was specifically designed to handle images for a window
> manager, so it works pretty well for that.
> The most obvious example is that it supports scaling images with an
> unscaled border region. Gdk-pixbuf doesn't, so sawfish has to do that
> by hand, and it's slowish (and possibly buggy in some corner cases)

There is really good (IMO) code for this in the gtk-engines/pixbuf.
Vastly better then imlib1, which honestly, is complete crap as far as
scaling and memory management goes. (I'm sure imlib2 is much better.)

 - It's smart about regions that are constant color or scale only
   in one direction
 - It has a neat feature for doing gradients (if the source region
   is 0 pixels in width, it interpolates)
 - It caches the source images, which really benefit from caching,
   it doesn't try to cache scaled images, which is just memory
   wastage on the server.
 - It's reasonably readable.

If you were using it with the old standalone gdk-pixbuf, there are
a few tweaks you would want to do, but mostly it should work 
either with that or the 1.3.x gdk-pixbuf.

> 2. I think Imlib uses less memory than the gdk-pixbuf+GdkRGB
> combination (GdkRGB allocates huge buffers on startup that account for
> a large percentage of sawfish's memory use)

The GdkRGB overhead is a a fixed per-process overhead that we can
attack per-process. As compared to Imlib overheads which are 
a) very hard to quantify. b) when it has been quantified, is usually
all caching stuff where the is no benefit to caching.

(GdkRGB overhead = 6*265*64*bytes_per_pixel, or ~200k for 16bpp.)

> 3. There are some bugs that only appear when sawfish uses gdk-pixbuf,
> e.g. doing partial exposes of window border regions seems not to work
> sometimes (this is probably a sawfish bug)
> And I think there were some other really strange bugs that appeared
> when Mandrake (?) starting compiling sawfish with gdk-pixbuf (they gave
> up and resorted to Imlib. Again this is probably something in sawfish
> that should be fixed, maybe to do with X errors)
> So in summary, it would be good to fix the gdk-pixbuf bugs in sawfish,
> but until then I don't recommend people compile sawfish with it (though
> I use it that way everyday, without any observed problems apart from
> the exposure problem mentioned above)

Well, as far as bugs go, would you rather deal with:

 gdk-pixuf: Part of core GNOME for GNOME-1, part of GTK+ for GTK+-2.0.
            GDK, several people actively work on bug fixing.
 imlib1: Not maintained.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]