Re: Inlining pixbufs
- From: Havoc Pennington <hp redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Inlining pixbufs
- Date: 24 Jun 2000 12:22:18 -0400
Tim Janik <timj@gtk.org> writes:
> > You're still saving an array, right, just a compressed one?
>
> nope, i'm using a string, that should be evident from the changelog
> entries.
>
I see a const guint8*, that looks like an array to me? (I suppose a
string and an array are the same thing... you are just saying you're
using a string literal I suppose)
> struct _BsePixdata
> {
> BsePixdataType type : 8;
> guint width : 12;
> guint height : 12;
> const guint8 *encoded_pix_data;
> };
>
OK, basically Owen suggested the following:
static const guchar apple_red [] =
{
/* File magic (decimal: 1804289383) */
0x6b, 0x8b, 0x45, 0x67,
/* Rowstride (decimal: 192) */
0x00, 0x00, 0x00, 0xc0,
/* Width (decimal: 48) */
0x00, 0x00, 0x00, 0x30,
/* Height (decimal: 48) */
0x00, 0x00, 0x00, 0x30,
/* Has an alpha channel (TRUE) */
0x01,
/* Colorspace (0 == RGB, no other options implemented) (decimal: 0) */
0x00, 0x00, 0x00, 0x00,
/* Number of channels (decimal: 4) */
0x00, 0x00, 0x00, 0x04,
/* Bits per sample (decimal: 8) */
0x00, 0x00, 0x00, 0x08,
/* Image data */
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
i.e. encode everything in a single stream of bytes. The encoded magic
at the start of the stream is in network order, so the byte stream is
architecture-independent, and theoretically you could dump it to and
from a file. Also it's conceivable to load the C source as you would
an XPM. The image data is just in RGBA order of course.
> something similar probably wouldn't be a bad idea for gdk_pixbuf, we
> can easily have a PixdataType flag that would indicate sharing of
> of static uncompressed data. and that interface is extensible for
> future refinements, such as more complicated compression algorithms
> for instance.
>
Agreed, I think the issue is just whether you want the struct or you
want to encode it in the byte stream. The byte stream has some
advantages, for example you could use it as a GtkSelectionData for
drag and drop, this is a feature that Qt has.
> you didn't look at bse_icon_from_pixdata() or CSource, right? all
> that logic is already there ;)
>
I saw it, yes. I see this morning that it's easier than I thought to
yank that code into my code, so I'll look at doing so.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]