<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>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.</span><span><br></span></div><div><span>It may not be important though :)<br></span></div><div><span><br></span></div><div><span>On a personal side, I agree with the last part "</span>In my opinion in the future for some engines <br>we will need to *require* external library support." So let's not fight it.</div><div>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.<span><br></span></div><div><span><br></span></div><div><div><span>Cheers,<br></span></div><div><span>Bertrand<br></span></div><br></div> <div style="font-size: 12pt; font-family: "times new roman", "new york", "times", serif"> <div style="font-size: 12pt; font-family: "times new roman", "new york", "times", serif"> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1"> <b><span style="font-weight:bold;">De :</span></b> Johannes Schickel <lordhoto@gmail.com><br> <b><span style="font-weight: bold;">À :</span></b> D G Turner <d.g.turner@ntlworld.com> <br><b><span style="font-weight: bold;">Cc :</span></b> scummvm-devel@lists.sourceforge.net <br> <b><span style="font-weight: bold;">Envoyé le :</span></b> Mercredi 25 juillet 2012 0h56<br> <b><span style="font-weight: bold;">Objet :</span></b> Re: [Scummvm-devel] png<br> </font> </div> <br>On 07/25/2012
12:10 AM, D G Turner wrote:<br>> Not to have an argument pointlessly... but I don't think that was the<br>> conclusion of the discussion.<br><br>I'm sure I missed some mails then. Eugene seemed to agree with switching <br>to libpng ("I would say it's better to switch to libpng now."). Willem <br>Jan seemed to favor a switch too. I'm for it too. So only md5 raised his <br>voice in the other direction, apart from you right now.<br><br>> Most of the thread indicated that (apart from the interlacing<br>> support, which has now been added), our internal PNG decoder is<br>> complete for our needs, so throwing it away and switching to an<br>> external library seems like alot of work for little improvement.<br><br>Well improvements would be: easier support for the PNGs out there. <br>Nobody would need to dig into the code and find where the interlacing <br>support is
broken right now. Since you also mention performance: libpng <br>is *probably* optimized for loading speed, unlike our code as far as I know.<br><br>And btw. this discussion was started *because* of the interlacing <br>support somaen added.<br><br>On the "oh this might be important, but right now it seems there's <br>nobody interested in it" side: Our PSP port uses libpng too. But I don't <br>know what PNG types it wants to display with it. It *might* even be PNGs <br>which are not support by somaen's interlacing support. But our PSP port <br>seems broken right now anyway. So this is all hypothetical...<br><br>> Also, the code required to "shim" the library to the image decoder<br>> API may result in worse overall performance, thus defeating the<br>> object of the optimised library speed improvement.<br><br>The keyword is "may" here. If this is really an issue it would be nice <br>to see some performance
measurements...<br><br>> If the Core team does decide to press ahead with this anyway, I would<br>> suggest that a solution is implemented where the internal PNG decoder<br>> is retained as a fallback for builds when libpng is not present, thus<br>> ensuring that this is not a mandatory build dependency.<br><br>This really defeats the point of using an external library. If we need <br>to maintain a fallback decoder anyway, there's no need to use an <br>external library. I don't see any reason to have a fallback anyway, <br>especially since engines using PNG, are performance hungry, and will <br>probably only run on platforms with libpng support anyway.<br><br>On a more general matter: In my opinion in the future for some engines <br>we will need to *require* external library support. For instance <br>releasing sword25 without Vorbis, Theora, zlib support will be low <br>quality for the
user, because of all the *standard* features he will <br>miss. And I hope you don't want to implement fallbacks for these now <br>too... WME is another example, as far as I got it, since it will require <br>FreeType 2 support for proper font rendering for example. And by chance <br>these engines are exactly the engines which will require libpng support, <br>while *no* other code uses it.<br><br>// Johannes<br><br>------------------------------------------------------------------------------<br>Live Security Virtual Conference<br>Exclusive live event will cover all the ways today's security and <br>threat landscape has changed and how IT managers can respond. Discussions <br>will include endpoint security, mobile security and the latest in malware <br>threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/"
target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a><br>_______________________________________________<br>Scummvm-devel mailing list<br><a ymailto="mailto:Scummvm-devel@lists.sourceforge.net" href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br><br><br> </div> </div> </div></body></html>