Re: Thoughts about a new GdkPixbuf transform interface

[Oleg Klimov <quif land ru>]

Bill Haneman wrote:
> >  - 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
#3?
M-m-m... I'm working on this stuff because I need it. I know what I
need:
š- arbitrary affine transform, speed
š- clear code
š- drawing (lines etc)
š- clipping region

Now I'm looking at your discussion of #1-2-3 and can't help but think:
who will need it?..
There are two ways of chaining transformations:
1. Write new algorithm that contain two transformations at once
2. Apply first, then second
You can't do 1 in general case. You can do 2, but result is loss of
šquality (example: two
rotations in a row, result is worse then one rotation on
angle1+angle2). Why build the
whole new 'tile' infrastructure to have the result identical (bad) to
just applying two
transformations? 30% memory saving (large images: src+dest+tmpbuffer,
last eliminated)?

But I rather consider reasonable to derive from Transformation object.