Re: Inlining pixbufs

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> On 24 Jun 2000, Havoc Pennington wrote:
> 
> > Tim Janik <timj@gtk.org> writes: 
> > > 1) what's that magic steaming from?
> > 
> > rand()
> 
> hm, we can do a tiny bit better ;)

rand() is a pretty good way of selecting unique identifiers. If there
are, say, a couple of thousands of possible magic strings we have to
distinguish ourself from, then 4 bytes from rand() give us a 1/million
chance of a conflict. Thats why I suggested it to Havoc. Using a
longer string that is "in the GDK namespace" probably is safe as
well. 
 
[..]

> > > 3) why have has_alpha, colorspace and n_channels? that's better encoded
> > >    in one 4 byte type field with an open flag convention (i.e. with something
> > >    like the enum BsePixdataType i use)
> > 
> > It's just a raw dump of Pixbuf; this is what Pixbuf has. 
> 
> yeah, and pixbuf has those fields because ArtPixbuf has them.
> there it actually makes sense, if you keep e.g. a font's RGBA
> bitmap image in memory, you can use offsets and rowstride to
> access the individual letters, but that's not the case with
> selection data or saved images where you have to care about
> offsets and rowstride yourself.

This sounds like you are forgetting how rowstride works. Rowstride gives
you the length of each line of the pixmap data. Handling a pixmap is
much more efficient if the rows are padded to 4 byte (or even greater)
alignment.

If the rows are padded, the data makes no sense without the rowstride,
unless you have an algorithmic way of computing the padding. (If we
want to say we always pad to 4 byte boundaries, then we can do that.
But simply writing the rowstride gives more flexibility if we decide
to later pad to bigger boundaries.)

Regards,
                                        Owen