[Scummvm-devel] png

Johannes Schickel lordhoto at gmail.com
Wed Jul 18 22:15:56 CEST 2012


On 07/18/2012 07:15 PM, Filippos Karapetis wrote:
> If you do wish to drop the custop PNG decoder, shouldn't we do the 
> same with the JPEG decoder and use libjpeg? IIRC, that one also had 
> missing features.

Maybe. As far as I know somaen found JPEG files which won't work with it 
either. So this might be something to think about.

On the other hand Groovie and Mohawk are less resource demanding than 
sword25 or WME (as far as I know), so switching there could be a 
*potential* problem for platforms which currently can barely support 
these engines. Sadly we don't have any data on memory consumption etc. 
of these engines on "low end" devices. So this is really just 
theoretical thoughts. For pratical testing it would be good to have some 
porter of a low end device compare memory consumption between our JPEG 
code and using libjpeg/libjpeg-turbo/whatever.


 > Which brings to my mind an issue. I wonder whether all of our ports 
incorporated freetype2? Seem not.

It seems indeed we didn't add FreeType 2 libraries to our buildbot for 
all platforms which should be able to handle it. Adding them for *all* 
ports is not really required, since fonts with FreeType 2 will consume 
considerably more memory than our BDF fonts and thus might result in 
port breakage. Since FreeType 2 support is optional, this is not much of 
an issue though. The speed issues tsoliman mentions might be fixable by 
using non-antialiased TTF fonts.


Back to the matter at hand: As I see it our PNG support is currently 
only really relevant for engines with high resource demands, thus using 
an external library like libpng is fine, since all platforms being 
capable of running the engines should be having it anyway. I don't think 
there is any need to worry about PNG support for other platforms, since 
it is just not used right now.

// Johannes




More information about the Scummvm-devel mailing list