On 11/09/2009 12:55 PM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > >> Actually, the *only* thing I do with jpeg is decompress the image, >> I don't really use any fltk-jpeg related things. By the time the >> stupid little image gets there, it's just an array of chars >> suitable for >> an RGB image. > > And that is all the functionality that we provide in the fltk built-in > jpeg support, which really is just a bundled copy of jpeg6b. > > It is also exactly *why* we provide the built-in jpeg support, so that > users of fltk can reliably and consistently handle the reading of jpeg > image files, without concern as to what the target platform or distro > happens to have installed. > > I honestly think that configuring your fltk lib with --enable-local-jpeg > set, and then linking statically to libfltk_jpeg.a will resolve pretty > much all the issues. > > >> But you see, this sort of finger pointing is precisely why I took the >> silly-looking route of doing the decompression in my own separate >> namespace. > > Which is what the fltk built-in libjepg is for, so it may be that you > are duplicating work that was already done? >
I'm not duplicating. As you say, the FLTK Jpeg support consists of reading and decompressing a named file from file systems. I don't read files. I have a buffer containing a compressed jpeg image. I could write it to a named file, but that would be the only reason I would need a writable file system. Bernd _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
