On Wed, 15 Aug 2001, Eric Faurot wrote:
> Christoph Egger writes:
> > On Tue, 14 Aug 2001, Eric Faurot wrote:
> >
> > > Hi all,
> > >
> > > Looking at libgpf, I noticed a few problems with the current
> > > highlevel API :
> > >
> > > - It doesn't handle palette formats.
> >
> > It doesn't do that as the result (the picture) is stored in a visual.
>
> huh? I thought it was not bound to ggi at all.
Oh, right... A long time passed as I designed it width Andy... :)
> > > - We can't initialize a image to write with a given size/frame
> > > number.
> >
> > gpfSelectImage() is for multiimage formats like gif. You can say I wanna
> > read the third frame of it. gpf handles a picture as a kind of streaming
> > data. The size is handled in lowlevel.
>
> But If I want to write a 4-image gif, how do I tell the driver?
You write the gif as one-data-stream. Use gpfWrite() to do that.
> > > - Writer and loader drivers must be separated to decrease
> > > the memory footprint on embedded systems, especially when
> > > encoding is complicated. ( maybe it was thought like this )
> >
> > This is done in the lowlevel API.
> >
> > > - The read/write callback should accept another void * argument
> > > to 'contextualize' the call. (I hate those context-less SAX
> > > parsers!)
> >
> > See lowlevel API.
>
> Well, it's not really obvious...
> I don't understand then how the highlevel API is supposed to be used.
> Is the code in CVS up-to-date ?
Yes. Nothing more hasn't been done yet. :-(
> > I wrote libgcp to handle that. It still doesn't handle everything,
> > what is needed for libgpf.
>
> I wonder if this could not take advantage of the batchop idea to
> transform between pixel layout.
Do you mean libgcp or libgpf should use the batchops?
Both libs are design long before the batchop idea came up... So I am open
for ideas.
> > > */
> > > int
> > > gpfRead(gpf_handle_t handle, gpf_pixelformat_t format,
> > > gpfReadCallback cbR,
> > > gpfIndicatorCallback cbI,
> > > void * data);
> >
> > Not needed. This is handled by the driver internally. The driver converts
> > data into a rgb data stream.
>
> This is ok as a default behaviour, but what if you want to get another
> layout? say, to feed a framebuffer.
Conversion will be required then. libgcp is your friend here.
> I thought of libgpf as generic way to get raster stream,
You get a raster stream, when reading. You write a raster stream, when
writing. Conversion is done between reading and writing.
> not a especially for loading an image in a visual (it's trivial
> though)
We can create a special highlevel function for this purpose as this might
be the most use of libgpf, I think.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
