Re: A request for future gdk_scale_pixbuf...

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

Hi Owen,

> [ Let me start off by saying, that gdk_pixbuf_scale/composite
>   is one of the API's I've done I'm more ashamed of - thee
>   is no excuse for a function call with 17 arguments like
>   gdk_pixbuf_composite_color() ]


Well, I don't even understand what that function does, so I won't 
penalize you ;)

> This simply doesn't work.  A typical usage of gdk_pixbuf_scale() for
> rendering a source pixbuf, scaled at some location at the destination
> pixbuf. As a simple case, I have a 200x100 source image and I want to
> render it at +100+100 with a size of 300x100


> This seems to fit your API exactly - but - in order to handle things
> like exposes, I also will need to be able to render subparts of the
> destination image. So, say that I need to render the portion of the
> destination image at +300+100 100x100. What's the corresponding source
> region of the image? +133.3333..+0 66.6666...x100


Well, here you're trying to satisfy a need that I'll never meet, 
admittedly. I do understand what you mean, but I'd like an alternative 
solution, so I'm probably going to work on getting my own scaling code 
working with MMX optimizations. In the meantime I want to understand the 
scale function properly though, as I certainly don't have time to debug 
my own code before needing to ship an alpha version of this software.

In my application, there will never be a time when I have to perform a 
partial window redraw of this kind, because it's not possible for any 
other window to obscure mine (as there is nothing else running on the 
machine!).

> So, you'd need at a minimum, floating point coordinates for source and
> dest rects. But in terms of keeping inaccuracy from creeping in when


Erm, no, let's keep the horror of floating-point numbers in an integer 
coordinate system at bay for just a moment :). You can solve this with a 
clipping rect (in the example I referred to earlier in OS/2 I think this 
is provided implicitly by the invalid region of the window being drawn 
to). So the call becomes
scale(sourcepbuf,srcx,srcy,srcwidth,srcheight,destpbuf,destx,desty,destwidth,destpbuf,clipx,clipy,clipwidth,clipheight)

At its simplest, unoptimized, this function does the full scale 
operation on the entire image, but it checks the destination pointer 
against the clip rect and doesn't perform the final store unless the 
pointer is inside that rect.

With some optimization, the function calculates the initial pointers and 
fractional counters for the clipped scale op and omits both read and 
write for pixels that would lie outside the clipped dest rect. That's 
what my PA-RISC code does (for fast panning of images that are zoomed 
larger than screen size). Unfortunately my code is (a) in an assembly 
language only slightly less obscure than cuneiform, (b) only works with 
5:6:5 RGB , but most importantly (c) is owned by my employer :(


> rendering subportions, I felt it was better to express the
> overall operation as:
>
>  * Transform the source image
>  * render part of the result


I'm coming to understand it better now that I'm experimenting with it. 
My goal is to get the scale and translate operation into one pass.

> There are other ways of expressing the transform - than 
> the scale_x, scale_y, offset_x, offset_y I used - probably
> a better would have been to have expressed it as via
> the x/y/width/height the entire source pixbuf has in the
> destination pixbuf under the transform.


I prefer the rect method over scale, if only for one reason: the 
function knows exactly how large, integrally, the caller expects the 
result to be, and can do a last-pixel fixup at the end of a scanline or 
bottom of a rect to make the image exactly the right size. When I was 
debugging my own scaling code, I had an endless, endless, ENDLESS horror 
with fencepost errors of this kind. There be many dragons in that code.

> [ Havoc promises to try to extract docs from this somewhat 
>   rambling email ]


:)


--
-- 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