Re: Thoughts about a new GdkPixbuf transform interface

[Bill Haneman <bill haneman sun com>]

On Wed, 2003-02-19 at 21:19, Owen Taylor wrote:
...
> Yes, TILE means wrap. (Though I'd say that applicability of FFT based
> methods only works for _affine_ transformations. If you have a
> non-linear spatial transform, then you can't use a fourier transform.)

Of course.  When I mention FFT I am thinking mostly of non-scaling,
non-affine transforms.

> [...]
> ...I'm hoping that if you
> have to write:
> 
>  gdk_pixbuf_transform_scale (transform, scale_x, scale_y);
>  gdk_pixbuf_transform_offset (transform, offset_x, offset_x);
>  gdk_pixbuf_transform_composite (transform, dest, 
>                                  dest_x, dest_y, dest_width, dest_height);
> 
> the model will be clear.

Yes, I think so.  It also allows reversing the order of offset+scale
operations if you want, which is a good thing IMO.

...

> Actually, all the current "smoothing types" fit perfectly into the model
> of reconstruction-function affine-transformation sampling-function.
> They aren't terribly _good_ filters, but they are mathematically 
> simple.

You're quite right, I wasn't thinking clearly enough :-)

> 
> > Alternatively we could have some kind of GdkPixbufFilter object, but
> > some of the smoothing/filters really need source as well as target info.
...
> > This would mean for instance that lots of GIMP filters could become
> > GdkPixbufFilters (which would be special cases of GdkPixbufTransform).  
...
[I suggested that subclasses could override a simple entry point like]
> >  
> > gdk_pixbuf_xform_get_tile (xform, source, target, subregion_foo)
> > 
> > or something like that, which fills a subregion of 'target' from
> > 'source' on demand.  Not sure what data struct to use for
> > subregion_foo... 
> > 
> > I don't want to complicate this idea out of existance; but I think that
> > providing this simple extension to the API would allow a simple
> > implementation of affine transforms while also supporting user-supplied
> > non-affine transforms (and eventual chaining of affine+non-affine
> > transforms, pull-model tiled transformation, etc.).
> 
> So, the proposal is that the affine-and- transformation object
> that I've proposed above would be just one implementation of generic
> GdkPixbufTransform and we could have other types of GdkPixbufTransform
> that did other operations?

Absolutely.

> 
> It's not a ridiculous idea; there is a certain elegance to it.
> 
> Though:
> 
>  - It makes things considerably more complex

I don't think it has to make the initial core implementation much more
complex (see below)... though of course I may be missing something here.

>  - You have end up with a choice for the pipeline of:
> 
>   [1]  - Pixel based. Possibly incredibly slow and inefficient
>       when you have steps that base one destination pixel
>       on multiple source pixels.
> 
>   [2]  - Do the whole image at each step of the pipeline.
>       Easy, fast, but you don't get any memory usage 
>       savings over a simpler interface without filter
>       chaining.
>     
>   [3]  - Tile based. Complex, complex, complex.

Yep.  My suggestion would be to choose implementation #2 first, but 
build the APIs with #2 in mind, so that enterprising people could patch
the smarter implementation in later.  'tilable' could even be a boolean
property, for those who objected to a behavioral change in a later
GdkPixbuf revision.

This would mean that the existing GdkPixbuf-type operations could be
quickly implemented using the new API, but compatible subclasses could
indeed get smarter.  

And it seems to me that the complexities of allowing non-affine
transformations would melt away if subclasses were required (in such
cases) to reimplement 

gdk_pixbuf_xform_get_tile (xform, source, target, subregion_foo);

The default implementations of GdkPixbufXform would call
gdk_pixbuf_xform_get_tile() on the whole region, and the default
implementation of gdk_pixbuf_xform_get_tile() would use something just
like the existing codepath, a linear translation+scaling algorithm.

But subclasses could do two things: they could add tiling support which
called gdk_pixbuf_xform_get_tile() on smaller subregions, and they could
replace gdk_pixbuf_xform_get_tile() with an arbitrary transformation.

AFAICS this wouldn't complicate the existing implementations
significantly, but would allow for considerable extension.  It might be
that other virtualized methods in GdkPixbufXform could be useful as
well, without significant complication to the stock/basic
implementations.

Lastly, it seems to be that if we are going to have GdkPixbufXforms that
can get scaled and translated, we might as well have:


GdkPixbufXform (abstract)
    -> GdkPixbufAffine [instantiate directly for skew xforms, etc.]
       --> GdkPixbufScale
       --> GdkPixbufTranslate


and then 

GdkPixbufAffine*
gdk_pixbuf_xform_composite (GdkPixbufAffine a, 
                                     GdkPixbufAffine b);


regards,

Bill

> Regards,
>                                              Owen
-- 
Bill Haneman <bill haneman sun com>