Re: GdkPixbuf vs. Cairo, new image library needed?



On Mon, 2007-10-15 at 09:04 -0700, Carl Worth wrote:
> On Sat, 13 Oct 2007 00:51:44 +0000, "=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=" wrote:
> > I have played around with Cairo some more and it seems to me that it
> > is not fully ready yet. :( Cairo blits and scales much slower than
> > gdk-pixbuf (software that is)
> 
> Do you have some simple test cases to demonstrate this so we can
> identify and fix anything necessary in cairo?

This would be a pretty interesting benchmark.  Any takers? :)

> > and doesn't support as good-looking bilinear filtering that
> > gdk-pixbuf does.
> 
> The scaling code in cairo, (for downscaling by factors greater than
> 2), could definitely use some improvement, (the current result is
> embarrassingly ugly). But what GdkPixbuf does here is actively bad for
> performance. I'd like to see some middle-ground implementation.

GdkPixbuf's scaling functions provide *very* nice results when
downscaling with GDK_INTERP_BILINEAR, though they are slow as you say.
High quality, but slow (for "slow" == "way slower than no
interpolation", or "I can't do 30 FPS for an image the size of my whole
screen").

I don't really know if there is a good, general solution for this.
There are several cases:

- Downscaling things once, like when generating a bunch of thumbnails or
scaling down big-wallpaper-1600x1200.png into something that fits in
your puny 1024x768 screen.  There's not much you can do here except
profiling the heck out of your one-time scaling algorithms.

- Downscaling things continuously, say, when interactively zooming in an
image viewer.  A stateful mip-map would help here, so you don't have to
recompute everything on every change of scale.  Note that you can play
tricks here:  EOG's beautiful zooming comes from doing a quick atomic
pass with no interpolation, and then doing bilinear interpolation of
small tiles in an interruptible fashion.

- People forget that "high quality rendering" and "good performance" are
at opposite sides of the scale :)  High-quality downscaling simply
requires you to look at a lot of source pixels to generate each
destination pixel.

Often people want to replay trivial code in their repaint functions,
such as taking a huge image, downscaling it, and painting it.  It's
better to scale image *once* and then reuse the result when you repaint.
That makes the program's logic more complicated, but that's life.

  Federico



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