[Scummvm-devel] png

[D G Turner]

Johannes,
  Not to have an argument pointlessly... but I don't think that was the
  conclusion of the discussion.

  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.

  I don't think we should add further library dependencies, unless we
  have very good reasons. Partly as they are generally not tested
  over the variety of platforms we target.

  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.

  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.

Thanks,
David Turner

P.S  libjpeg has been a slightly different issue as the IDCT does
     benefit from hardware acceleration support... but this is somewhat
     pointless as this is mainly available on high-end/desktop targets
     which are not the problematic case.

On 07/24/12 22:53, Johannes Schickel wrote:
> On 07/18/2012 04:57 PM, Willem Jan Palenstijn wrote:
>> Given the missing features (and/or bugs) in our current PNG decoding
>> [ https://github.com/scummvm/scummvm/pull/258 ], should we revisit our choice
>> not to use libpng? That seems to me to be the easiest way to get all required
>> features in a well-tested and supported form.
>>
> 
> As far as I can tell, most people agree it's fine to switch to libpng. 
> So who will look into implementing this change?
> 
> // Johannes