[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