now that bug 168048 has combined a bunch of decoders into imglib2.dll, we need a mechanism to turn on or off individual decoders. What I'm imagining is that there will be a default list of encoders, and that a series of defines will be available both in the makefiles and the C++, like IMGLIB_BUILD_gif or something, similar to the extensions mechanism. Then I'll add a bunch of #ifdefs to the stuff in modules/libpr0n cc'ing seawood for help/recommendations.
over to 1.3 for now.
Created attachment 110984 [details] [diff] [review] v1.0 I basically copied the --enable-extensions code for the configure portion of the patch. In order to avoid doing full rebuilds whenever someone changed their image-decoder configure setting, I put the defines in the local Makefile since they are only used in one place. That hack required adding Makefile as a dependency to a bunch of the common rulesets that were only dependent upon Makefile.in .
Comment on attachment 110984 [details] [diff] [review] v1.0 looks good, r=me
Comment on attachment 110984 [details] [diff] [review] v1.0 nice. sr=alecf
Patch has been checked in.
How does this interact with the hardcoded list of image types at http://lxr.mozilla.org/seamonkey/source/content/build/nsContentDLF.cpp#117 ? What happens if one loads an image which has a mimetype in that list, but no decoder available? (ie. not as part of a page, but directly)
That list contains image/x-art. Afaik, none of these decoders work for the ART image type so that list seems to be just a set of hardcoded hints. If the decoder is missing, then it just refuses to render that type of image. If you click on the image, it brings up the download dialog.
yeah, I know that the list contains ART, but art images aren't exactly common on the web... But anyway, thanks for testing this.