Re: GdkPixBuf

[Mark Crichton <crichton expert cc purdue edu>]

On Sat, 7 Aug 1999, Christopher T. Lansdown wrote:

> Hi,
> 	I've heard a little about the upcoming pixbuf which is a
> replacement for imlib.  Will it have the capability to load images from
> memory just as if they were a file?  Imlib doesn't seem to be able to do

I'd like it to.  And in the cases for XPM and PNG, they'll be able to.  I
didn't do the JPEG loader, so I don't know if it can load from memory. 
GIF might be able to load from memory, but I dont remember if libungif can
do that. TIFF is going to be problematic, since libtiff doesn't seem to
support reading images from memory (I'm probably going to have to resort
to an ugly "save the mem image to /tmp and load from a file). 

> sufficient functionality to avoid that be in the PixBuf routines?  Btw,
> will the pixbuf routines also make life really easy in terms of reading
> many different image formats and having fallbacks like imlib did, as well
> as being colordepth independent?  Thank you.

The one thing that scared the pants off me was imlib just happily running
convert in the background.  For fallbacks, the current method is if we
dont have a loader for the file, it's not going to get loaded (but as of
right now, we have the major formats (XPM, GIF, PNG, JPEG, TIFF)
supported, and BMP and PPM are in the works).  It's also pretty simple to
write your own loader as well.

Also, since PixBuf will be working with libart, ALL pixbufs will be a 24
bit RGB or 32 bit RGBA image.  This allows 2 things:

1) Use with libart to do affine transforms (scaling and rotation are
supported in the pixbuf lib right now, translation will be added, and if
you know how affine transforms work, you can set up your own affine matrix
and do your own transforms)

2) The 24/32 bit format is ready for output through GdkRGB.  This frees
you up from worrying what type of display you're running on, since GdkRGB
will do the dithering for you, and do it right (and do it really fast)

Mark