Re: Equivalent to gdk_draw_rgb_image that scales output?

[Havoc Pennington <hp redhat com>]

"Lewin A.R.W. Edwards" <larwe larwe com> writes: 
> Hmm. I guess I will try benchmarking my own code against the pixmap
> functions. Thanks for the direction.

Right - if it wasn't clear, the code I'm referring to is in the
gdk-pixbuf lib, which is distributed separately from GTK 1.2.

> Just in case you happen to have a great idea for me to poke into -
> Given that I'm stuck with XFree86 3.3.6 (my hardware isn't supported
> under 4.x), and also given that my source images are at sizes that
> will usually be out of my control, what's the fastest drawing strategy
> you can think of? At the moment I have a single window with a drawing
> area inside it, covering the entire screen. I decode my image data
> into an external buffer at whatever size it arrived at (I can't
> decimate it at that point - I need to leave it fullsize, because the
> user might request a zoom or an orientation change, and decoding the
> image to RGB 8:8:8 is a very time-consuming operation - I want to do
> it just once at full resolution, cache the decoded copy, and work from
> that). I then have to use my own decimation code to get the data into
> a screen-sized RGB buffer, then gdk_draw_rgb_image to get it into the
> window. All of those operations are pretty slow and ugly.

Well, the fastest thing in principle is to take the source image, and
scale it directly into a GdkImage buffer, then gdk_draw_image() the
GdkImage over to the drawing area. But that's a _lot_ of work, because
GdkImage's format varies with the hardware. If you can afford to have
your code only work on your specific setup, then it might be feasible
since you only have one GdkImage format to worry about.

> BTW, thanks also for your earlier response on hiding mouse cursor, it
> worked :) However the unref functions don't appear to be present in
> the version of gtk I'm using - not an issue for me, just an fyi.

Ah, right - you probably want gdk_cursor_destroy() in GTK 1.2.

Havoc