[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New image loaders (step 1)

From: Alexander Malmberg
Subject: New image loaders (step 1)
Date: Thu, 08 Jan 2004 13:59:51 +0100


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:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]