"Andreas Pokorny" <andreas.pokorny@gmail.com> wrote in message news:AANLkTinNYQxRcDrkD_Hrw2z6YASbDypLUdTWhQbOXeb3@mail.gmail.com...
I think we should get rid of those backends entirely. Phil stated interesting use cases in a different thread, that might not be accomplished with these libraries. Additionally to that I made bad experiences with libpng and non broken but somehow not conformant png images.
There are alternatives to using libpng and libjpeg: * LodePNG: http://members.gamedev.net/lode/projects/LodePNG/ * STB_Image http://nothings.org/stb_image.c
I havent used the stb jpeg loader, but I switched to lodepng for the non-gil code.
IMO GIL.IO should not make the decision on the backends used (as io and io_new currently do), instead it should provide wrappers around different backends that provide a unified interface and let the user decide which backend to use (as io2 does)... For the same reason a decision to simply switch from LibPNG to LodePNG would be equally 'wrong'...as there are many factors that influence the choice of the backend that a particular user might want (or need to use)...e.g. a GUI library might force/prefer the use of a particular backend... But the whole xjmp issue is a bit overblown IMO as there are two solutions that are easily implementable, one is the 'always-safe-albeit-less-efficient-one', to wrap all LibXXX calls that can call longjmp and convert the call in setjmp to a C++ exception and the other is to simply throw from the error callbacks for platforms/compilers/build setups that can throw through the LibXXX code... Furthermore, if no unwindable objects are used during the decoding of an image (as is the case with io2 when the target is a raw/non-virtual GIL image) the solution is even simpler (no need for constant setjmp calls in wrappers)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman