For PNG, if it could decode a handful of (say 8) rows at a time, there might be scope to optimise the filters more aggressively.  I've never taken the time to look closely at the viability because everybody seems locked in to the one-row interface.

Could this ever change?


The optimisation involves transposing staggered blocks and working diagonally across a strip.  It'd work best with not too much per-row filter variation, but there's an adaptable version which might cope despite that.

I would be more than happy to assist with changes to work on units other than single rows. Single row seems pretty arbitrary.

> everybody seems locked in to the one-row interface

Do you mean png_read_row? Chromium uses the callback interface, which calls Chromium's method each time a row is available.

scroggo@ is right that Chromium does not depend on a row-by-row interface.  But that idea is somewhat ingrained in libpng.  This might be a good topic for upstream: https://github.com/glennrp/libpng.