[Scummvm-devel] png

[Johannes Schickel]

On 07/25/2012 12:10 AM, D G Turner wrote:
>    Not to have an argument pointlessly... but I don't think that was the
>    conclusion of the discussion.

I'm sure I missed some mails then. Eugene seemed to agree with switching 
to libpng ("I would say it's better to switch to libpng now."). Willem 
Jan seemed to favor a switch too. I'm for it too. So only md5 raised his 
voice in the other direction, apart from you right now.

>    Most of the thread indicated that (apart from the interlacing
>    support, which has now been added), our internal PNG decoder is
>    complete for our needs, so throwing it away and switching to an
>    external library seems like alot of work for little improvement.

Well improvements would be: easier support for the PNGs out there. 
Nobody would need to dig into the code and find where the interlacing 
support is broken right now. Since you also mention performance: libpng 
is *probably* optimized for loading speed, unlike our code as far as I know.

And btw. this discussion was started *because* of the interlacing 
support somaen added.

On the "oh this might be important, but right now it seems there's 
nobody interested in it" side: Our PSP port uses libpng too. But I don't 
know what PNG types it wants to display with it. It *might* even be PNGs 
which are not support by somaen's interlacing support. But our PSP port 
seems broken right now anyway. So this is all hypothetical...

>    Also, the code required to "shim" the library to the image decoder
>    API may result in worse overall performance, thus defeating the
>    object of the optimised library speed improvement.

The keyword is "may" here. If this is really an issue it would be nice 
to see some performance measurements...

>    If the Core team does decide to press ahead with this anyway, I would
>    suggest that a solution is implemented where the internal PNG decoder
>    is retained as a fallback for builds when libpng is not present, thus
>    ensuring that this is not a mandatory build dependency.

This really defeats the point of using an external library. If we need 
to maintain a fallback decoder anyway, there's no need to use an 
external library. I don't see any reason to have a fallback anyway, 
especially since engines using PNG, are performance hungry, and will 
probably only run on platforms with libpng support anyway.

On a more general matter: In my opinion in the future for some engines 
we will need to *require* external library support. For instance 
releasing sword25 without Vorbis, Theora, zlib support will be low 
quality for the user, because of all the *standard* features he will 
miss. And I hope you don't want to implement fallbacks for these now 
too... WME is another example, as far as I got it, since it will require 
FreeType 2 support for proper font rendering for example. And by chance 
these engines are exactly the engines which will require libpng support, 
while *no* other code uses it.

// Johannes