> And: Should we even be maintaining our own GIF decoder now? The (LZW)
> patents have lapsed, so we could maybe incorporate libgif (or similar)
> as we do libpng et al, and thus gain the ability to read and write GIF
> files, and process animated GIF and so forth...?
Just to throw my two cents in here, I'm all for the libgif/similar idea. I had
hacked up a small gif animator for a personal project that I had derived from
fltk2's Image class (I had to override the fetch method and all), but this was
a ton of work for such a small project.
I'd be happy to look into bashing together a new gifImage::fetch() method for
fltk2, but Ian has a point here. In terms of performance I don't think fltk
will suffer from a huge dip because there should really only be a few function
calls here and there thrown in, and it will certainly make life a hell of a lot
easier.
Alternatively, a few other ways I've seen this implemented is with a simple
daisychain of images (a la linked list), and this shouldn't actually be that
hard to implement, aside from rewriting the fetch() method.
Feel free to discard those two cents; I've certainly never cared for coppers.
:-)
Ben
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
