[Scummvm-devel] png

[Bertrand Augereau]

Just a sidenote guys, libpng is not optimized, it is more of a reference code with portability in mind. No SIMD nor per-platform code there.

It may not be important though :)


On a personal side, I agree with the last part "In my opinion in the future for some engines 
we will need to *require* external library support." So let's not fight it.
But if we have a light PNG decoder that does most of the job, let's keep it as an option for people who don't have a libpng dependency (maybe Win32 guys who don't want to install another library for instance) and keep it for a few months.


Cheers,

Bertrand



________________________________
 De : Johannes Schickel <lordhoto at gmail.com>
À : D G Turner <d.g.turner at ntlworld.com> 
Cc : scummvm-devel at lists.sourceforge.net 
Envoyé le : Mercredi 25 juillet 2012 0h56
Objet : Re: [Scummvm-devel] png
 
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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Scummvm-devel mailing list
Scummvm-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scummvm-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20120725/51af959f/attachment.html>