Re: Thoughts about a new GdkPixbuf transform interface

[Bill Haneman <bill haneman sun com>]

Owen says:
> 
>  - The 17 arguments to gdk_pixbuf_composite_color()
>  - Nobody understands it
>  - Not extensible ... I'd like to add the choice of what to 
>    do for source pixels off the edge of the source from
>    RENDER.
>  - No support for rotation (or other arbitrary transforms)

I agree absolutely, I'm delighted to see this topic being raised.

> What I was thinking of:
> 
> GdkPixbufTransform *gdk_pixbuf_transform_new (GdkPixbuf *source);

[snip rotate, scale, arbitrary affines, etc.; Oleg, affine
transformations are arbitrary linear transformations that can be
specified via a matrix]

I like the idea of allowing compositing of xforms into a single
transform object for subsequent application, cool.

Eventually we could even consider a 'pull model' like Java2d's so that
only the parts of the pixbuf result that weren't clipped away would be
created, thus allowing larger scale factors, etc., while retaining
bincompat and ABI compat going forward.  IOW we could make it smarter in
later releases.

..

> typedef enum GdkPixbufEdgeMode {
>   GDK_PIXBUF_EDGE_NEAREST,
>   GDK_PIXBUF_EDGE_TRANSPARENT,
>   GDK_PIXBUF_EDGE_TILE
> };

Hmm, what about WRAP? If we had non-affine transformations this could
matter, for instance if you are using FFT to do your transformations. 
Is that what you meant by "TILE" ?

> /* Specify what to do for source pixels off the edge */
> void gdk_pixbuf_transform_set_edge_mode (GdkPixbufTransform *transform,
> 					 GdkPixbufEdgeMode   mode);
> 				     

> 
> Notable differences from the old API:
> 
>  - Have an explicit object
Yay

>  - Add edge mode
Yay

>  - Add arbitrary transformation
Yay, but let's allow non-affine transformations as well.

>  - Making the "transform then render a portion   of the transformed object" 
>    model explicit hopefully makes it easier.
[not sure what you mean here I'm afraid]

>  - Checks feature of composite_color() removed. Was a silly demo-app thing,
>    and won't be significantly faster than just filling a destination
>    pixmap.
> 
> Main problem I see with the proposal is the name ... not crazy
> about GdkPixbufTransform; GdkPixbufCompositor was another idea,
> but even long.

GdkPixbufXform ?  

As for "why do we need non-affine transforms", note that in effect we
already have some implicit non-affine behavior in our smoothing types. 
Alternatively we could have some kind of GdkPixbufFilter object, but
some of the smoothing/filters really need source as well as target info.

For example, gnome-mag needs to do not only pixbuf scaling but various
kinds of smoothing (for instance thresholding or font/image smoothing),
since the blurring introduced by bilinear interpolation can reduce
legibility of scaled text.  In the more general GdkPixbuf world, it'd
allow us to plug various image processing doodads/algorithms into
GdkPixbuf without having to hack into the pixbuf data from both source
and dest, and post-process it (which is what is now required).

This would mean for instance that lots of GIMP filters could become
GdkPixbufFilters (which would be special cases of GdkPixbufTransform).  

I guess what I'm suggesting is that GdkPixbufXforms be chainable and
potentially non-affine, as well as user-subclassable, with a couple of
trivial methods like 

gdk_pixbuf_xform_is_affine ()
gdk_pixbuf_xform_get_matrix () [valid only for affine xforms]

and methods sufficient for overloading in subclasses 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.).

regards,

Bill

-- 
Bill Haneman <bill haneman sun com>