Re: A request for future gdk_scale_pixbuf...

["Lewin A.R.W. Edwards" <larwe larwe com>]

Hi Havoc,

>Have a look at the implementation of scale_simple:


scale_simple has two drawbacks, one of which is generic enough that 
others might be concerned about it, the other of which is pretty 
specific to my application:

The specific one is that scale_simple allocates a new pixbuf which then 
has to be destroyed. I don't want to do this. I avoid dynamic memory 
allocation STRENOUSLY in my application; in fact, I have a private heap 
management system and some watchdog type code.

The general drawback is that the current code creates a need for extra 
steps. In particular, I have a generic function that takes the source 
image and translates it to an offscreen buffer (this buffer is 
screen-sized), according to user-defined rules. The possible rules are 
"stretch", "fit" and "center". In "stretch" mode, the source is dumbly 
scaled to fit the destination geometry exactly. No problem there. In 
"fit" mode and "center" mode, things get grayer. In "fit" mode, the 
picture is rendered onscreen at the maximum possible size without 
changing its aspect ratio. This means that the destination blit doesn't 
necessarily start at (0,0), and in "center" mode if the source is larger 
than the screen (meaning that only a window out of the center is being 
rendered), the source blit doesn't either.

BTW, I don't understand fully what the *_offset parameters are, nor why 
they are declared as double. Are they proportional offsets or integer 
(pixel) translations, and are they in the source or destination space?

>In GTK 2 you can create a "subpixbuf" of the source image, in order to


Aha. That's more like what I'm looking for. Although I guess I can 
achieve the same result in 1.0 by using gdk_pixbuf_new_from_data and 
adjusting the source pixel pointer.



--
-- Lewin A.R.W. Edwards (Embedded Engineer)
Work     http://www.digi-frame.com/
Personal http://www.larwe.com/
Tel (914) 937-4090 9am-6pm ET M-F