Actually, the problem with libpng is that it's a required library. i.e. if we sit back and<div>think which are the bare-bones necessary libraries for compiling ScummVM, it's</div><div>just libsdl... and nothing else. libmad, libogg, libflac and libtheora are all optional.</div>
<div>If they're not included, a feature is missing. But libpng is the only exception here: it</div><div>is required in order to play Broken Sword 2.5.</div><div><br></div><div>The usage of libpng in this case lies in the same category as libjpeg in mohawk,</div>
<div>which makes extensive usage of JPEGs. But with mohawk we rolled our own JPEG</div><div>reader, whereas with sword25 we added libpng. Isn't that a bit contradicting? And</div><div>since the PNG reader is working, what is the problem with it? Yes, it won't be as</div>
<div>optimized as libpng, but that's not its point. We don't need all of the features that</div><div>libpng provides, as ScummVM isn't an image viewing program. E.g. we don't need</div><div>to read the text blocks off a PNG image, or its embedded ICC profile, or its</div>
<div>histogram. The point is to have a bare-bones PNG reader code, useful for games,</div><div>not an image viewer application. So again, I ask: why should we keep PNG as a</div><div>required library for features that we don't need?</div>
<div><br></div><div>Regards</div><div>Filippos</div><div><br><div class="gmail_quote">On Wed, Feb 2, 2011 at 9:49 PM, Willem Jan Palenstijn <span dir="ltr"><<a href="mailto:wjp@usecode.org">wjp@usecode.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Feb 02, 2011 at 09:13:01PM +0200, Filippos Karapetis wrote:<br>
> The discussion boils to "do we want to have our own code for handling file<br>
> formats, or use external libraries?"<br>
<br>
</div>I don't think that's what the discussion boils down to at all, and see no<br>
reason why we should treat everything the same. I think we should ask this<br>
question on a case-by-case basis, based on things like code size,<br>
maintainability, portability, performance.<br>
<br>
At this point there seems to be no concrete gain to dumping libpng, since the<br>
platforms where we use it for sword25 seem to have no issues with libpng?<br>
<br>
Unless it's an issue on the PSP where we also seem to use libpng?<br>
<font color="#888888"><br>
<br>
-Willem Jan<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
> On Wed, Feb 2, 2011 at 8:54 PM, Johannes Schickel <<a href="mailto:lordhoto@scummvm.org">lordhoto@scummvm.org</a>>wrote:<br>
><br>
> >  On 02/02/2011 07:04 PM, Filippos Karapetis wrote:<br>
> ><br>
> ><br>
> >  > png.*<br>
> >> As I expressed on IRC, I disagreed with having our own PNG decoder and<br>
> >> I would much rather see libpng used. The dependency on libpng is not<br>
> >> something that would be ridiculous to depend on and we will most<br>
> >> likely never equal the speed of libpng.<br>
> ><br>
> ><br>
> >  Why? We don't need all of the functionality of libpng, and it's not like<br>
> > we absolutely<br>
> > need top speed when loading an image. We have our own code for all the<br>
> > other<br>
> > image formats, why is it so wrong in having our own code for PNG as well?<br>
> > One<br>
> > less dependency is a good thing in my eyes, especially if it allows us to<br>
> > port the<br>
> > game in other platforms and not worry about libpng availability there. So,<br>
> > I personally<br>
> > don't understand why libpng is better for our needs.<br>
> ><br>
> ><br>
> ><br>
> > Uhm, don't we already use libpng for PNG loading in Sword2.5 and the PSP<br>
> > backend? I rather thought this was about moving the decoders to its own<br>
> > subdirectories (+ unifying the API) instead of duplicating the code and not<br>
> > about how to implement the loader?<br>
> ><br>
> > Ahh I see Md5 implemented a custom PNG loader... well I am not too happy<br>
> > about that. I do not think libpng is a library which is hard to port (you<br>
> > can proof me wrong here though), also why should we spend time writing a<br>
> > good (i.e. consider speed, memory consumption, fail safenes, etc.) PNG<br>
> > loader/(encoder?) implementation, when we can just use libpng? That seems<br>
> > wasted time we could rather put into improving our other code IMHO.<br>
> > Personally I am not sure why we do not use libjpeg for JPG loading...<br>
> ><br>
> > Also we should consider the target systems of the engines we use those<br>
> > image loaders for, just take Sword2.5, on which devices are we likely to get<br>
> > it to run and which device of these will have any problem with a libpng<br>
> > depandancy?<br>
> ><br>
> > All this seems premature optimization to me, if we have a stable image<br>
> > decoding API we can exchange the implementation when we have any problems<br>
> > later on anyway, so why do we now want to implement every standard image<br>
> > format loader out there ourselves? Just to not depend on a library which is<br>
> > (probably) pretty easy to use on most of our target systems? That reasoning<br>
> > seems strange to me....<br>
> ><br>
> > Since you mention loading speed: Didn't we have some problems with the JPG<br>
> > loader being slow and thus we needed to optimize it (or still do? I remember<br>
> > something about that and if anyone would remember the details I would be<br>
> > most pleased if he / she could clarify that here.<br>
> ><br>
> > // Johannes<br>
> ><br>
> ><br>
> > ------------------------------------------------------------------------------<br>
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!<br>
> > Finally, a world-class log management solution at an even better<br>
> > price-free!<br>
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires<br>
> > February 28th, so secure your free ArcSight Logger TODAY!<br>
> > <a href="http://p.sf.net/sfu/arcsight-sfd2d" target="_blank">http://p.sf.net/sfu/arcsight-sfd2d</a><br>
> > _______________________________________________<br>
> > Scummvm-devel mailing list<br>
> > <a 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>
><br>
><br>
> --<br>
> "Experience is the name every one gives to their mistakes" - Oscar Wilde<br>
<br>
> ------------------------------------------------------------------------------<br>
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!<br>
> Finally, a world-class log management solution at an even better price-free!<br>
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires<br>
> February 28th, so secure your free ArcSight Logger TODAY!<br>
> <a href="http://p.sf.net/sfu/arcsight-sfd2d" target="_blank">http://p.sf.net/sfu/arcsight-sfd2d</a><br>
> _______________________________________________<br>
> Scummvm-devel mailing list<br>
> <a 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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>"Experience is the name every one gives to their mistakes" - Oscar Wilde <br>
</div>