Re: gtk-devel-list digest, Vol 1 #1739 - 7 msgs

[Bill Haneman <bill haneman sun com>]

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

Well, I know that I already need it (for magnification work, etc.)

> 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 chain affine transformations trivially without significant loss
of quality, via matrix mult.  That's one of the reasons I proposed it,
so that it would be easy and not-very-expensive to chain multiple
translate/rotate/scale operations together.

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

With a tile infrastructure it becomes possible to do things which
otherwise would take waaay too much memory.  And chaining affines would
avoid a lot of data duplication (as opposed to maintaining separate
GdkPixbufs at each step).

> But I rather consider reasonable to derive from Transformation object.

I agree with Owen, I think it's well within scope for gtk+.  And if we
are going to have a pixbuf transformation API at all, we should make it
at least theoretically tileable and extensible.

At some point you want a full imaging API I concede, but the problem
that arises if we don't think about this in the the GdkPixbuf context is
that you end up with incompatible APIs and extra conversions to and from
GdkPixbuf; don't we already do enough of that when dealing with
GdkDrawable/GdkPixmap?

I think we should have a GdkPixbuf API that can be compatibly built on
by a future library, so that such conversions are not generally needed;
then the more advanced imaging operations could be performed directly on
GdkPixbufs rather than some new data structure, and the APIs would be
consistent and familiar.

I hate having to deal with multiple 'image/transform' APIs that have
been developed to meet 'different' needs without thinking about this,
for instance Java2D, java.awt.image, java3d, Java Advanced Imaging,
etc... ugh!  Such a shame that they aren't part of a more consistent and
more-interoperable framework.  I think we can learn from this...

-Bill

-- 
Bill Haneman <bill haneman sun com>