Re: GdkPixbuf image depth



On Mon, Jan 13, 2003 at 12:14:36PM -0500, Owen Taylor wrote: 
But conceptually I could definitely see supporting:

 - A more normal alpha format like 32-bit word premultiplied ARGB
 - 16 bit per channel

And perhaps even alternate color spaces like CMYK.

How do you support scaling, compositing, and conversion to/from
GdkImage for all those?  Maybe by just converting all pixbufs to the
same format, doing the operation, then converting back, but that makes
any format that isn't the "master" format really slow. And even right
now, a bunch of the special cases in gdkpixbuf-drawable.c/gdkrgb.c
have historically been pretty buggy/untested. If RGB<->555 is not
tested much, imagine CMYK<->555.  M*N rarely tested codepaths
containing quite a bit of code:

  $  grep ';' gdkrgb.c gdkpixbuf-drawable.c | wc -l
     2025
  (Almost all of that RGB-specific.)

Clearly the current GdkPixbuf API was designed to allow adding
formats, but in practice people heavily rely on it being in a single
format, and I would argue they do so because that's what makes
GdkPixbuf useful. Hardware-independent is not the main point - if I
have to write special-case code for 30 formats, it does not matter if
the 30 formats are a function of the hardware, or the 30 formats are a
function of what some random other code module decided to use. It
still means doing 30x as much work. That's why GdkImage is completely
useless in most instances and converting it to/from a GdkPixbuf is the
standard mode of operation.

So if we add other formats, I would expect (hope, really) that most
code will implicitly require the current RGB/RGBA, and the other
formats will only be used in custom applications. CMYK is a very
special-purpose thing that <1% of apps have any use for. And there's
no guarantee they could use GdkPixbuf; could the GIMP use GdkPixbuf
for its image buffers?

The disaster case is that we add other formats and more than one
becomes popular outside of special-purpose apps - then every app ends
up *having* to handle multiple formats, and we lose the benefit of
standardizing on RGBA, and GdkPixbuf is just as
annoying/impossible-to-get-right as GdkImage.

So basically by definition we want all non-RGBA formats to be rarely
used, or at least never used to pass pixbufs between modules...

Anyway, all academic until we get the largish patch required to
support additional formats.

Havoc



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]