Re: New image loaders (step 1)

[Alexander Malmberg]

Well, step 2 is done and committed, and step 3 is done locally, so I'm
just waiting for feedback. Seems the original mail was lost, or heavily
delayed. I'm quoting all of it here; hopefully, this one will be
delivered.

- Alexander Malmberg

Alexander Malmberg wrote:
> Hi,
> 
> I have now (finally :) committed three of the new image loaders: PNG,
> JPEG, and PNM. The PNG and JPEG loaders use libpng and libjpeg
> respectively. The PNM loader is self-contained. Some highlights of the
> new loaders:
> 
> * They load from raw data and don't rely on file extension tricks to
> detect images.
> 
> * They're thread-safe (ie. you can load images from more than one
> thread; each individual NSBitmapImageRep instance still needs to be kept
> to one thread).
> 
> * They're independent of the backend, so backends not using back/x11/
> can now load jpeg:s/png:s.
> 
> * They work. :) There have been several reports of crashes when GNUstep
> apps load .png images, and it's always been tracked down to broken code
> in libwraster. The new png loader does not have these issues; it loads
> images that the old loader crashed on, and it loads all valid images in
> the png test suite (and reports an error instead of crashing on the
> invalid images).
> 
> However, due to an implementation quirk, the wraster image loading code
> is sometimes tried before the new loaders, so things crash anyway. Once
> the wraster image loading code has been removed, this will be fixed.
> 
> * We can actively check for jpeg/png support. ./configure in -gui will
> now fail if libjpeg/libpng can't be found:
> ""
> GNUstep requires libjpeg to support JPEG images, but this library
> can't be found. If you really want to compile GNUstep without
> JPEG support, pass the --disable-jpeg option to ./configure.
> Note that this isn't recommended. For more information, see:
> http://gnustep.made-it.com/BuildGuide/index.html#JPEG
> ""
> 
> Thus, you can still compile -gui without jpeg/png support, but you're
> unlikely to do so by accident.
> 
> Note that this is done, I want to proceed with:
> 
> Step #2: Add the new gif (libungif) loader. I just need to do the final
> configure work, cleanups, and testing here.
> 
> Do we want a strict configure check for gif support as well? (Ie.
> ./configure fails if libungif isn't there unless you give an explicit
> --disable-gif.) I think png and jpeg are formats you definitely want
> support for nowadays, but I'm not sure about gif.
> 
> Step #3: Remove the wraster image loading hacks. I think this will be a
> very Good Thing, but I guess I'd better ask first: Can anyone think of
> any good reason why we'd want to keep it? (And if so, are you willing to
> fix it and maintain it? :)
> 
> - Alexander Malmberg