[Scummvm-devel] Moving and merging image-related code

[Johannes Schickel]

On 02/02/2011 07:04 PM, Filippos Karapetis wrote:
>
>     > png.*
>     As I expressed on IRC, I disagreed with having our own PNG decoder and
>     I would much rather see libpng used. The dependency on libpng is not
>     something that would be ridiculous to depend on and we will most
>     likely never equal the speed of libpng.
>
>
> Why? We don't need all of the functionality of libpng, and it's not 
> like we absolutely
> need top speed when loading an image. We have our own code for all the 
> other
> image formats, why is it so wrong in having our own code for PNG as 
> well? One
> less dependency is a good thing in my eyes, especially if it allows us 
> to port the
> game in other platforms and not worry about libpng availability there. 
> So, I personally
> don't understand why libpng is better for our needs.
>

Uhm, don't we already use libpng for PNG loading in Sword2.5 and the PSP 
backend? I rather thought this was about moving the decoders to its own 
subdirectories (+ unifying the API) instead of duplicating the code and 
not about how to implement the loader?

Ahh I see Md5 implemented a custom PNG loader... well I am not too happy 
about that. I do not think libpng is a library which is hard to port 
(you can proof me wrong here though), also why should we spend time 
writing a good (i.e. consider speed, memory consumption, fail safenes, 
etc.) PNG loader/(encoder?) implementation, when we can just use libpng? 
That seems wasted time we could rather put into improving our other code 
IMHO. Personally I am not sure why we do not use libjpeg for JPG loading...

Also we should consider the target systems of the engines we use those 
image loaders for, just take Sword2.5, on which devices are we likely to 
get it to run and which device of these will have any problem with a 
libpng depandancy?

All this seems premature optimization to me, if we have a stable image 
decoding API we can exchange the implementation when we have any 
problems later on anyway, so why do we now want to implement every 
standard image format loader out there ourselves? Just to not depend on 
a library which is (probably) pretty easy to use on most of our target 
systems? That reasoning seems strange to me....

Since you mention loading speed: Didn't we have some problems with the 
JPG loader being slow and thus we needed to optimize it (or still do? I 
remember something about that and if anyone would remember the details I 
would be most pleased if he / she could clarify that here.

// Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110202/539b31cf/attachment.html>