Re: [PATCH v2] arm: Don't require a runtime check function for targets with unconditional NEON

On Wed, Oct 12, 2022 at 1:14 AM John Bowler
<[email protected]> wrote:
>
> On Tue, Oct 11, 2022 at 1:06 PM Bob Friesenhahn <[email protected]> wrote:
>>
>> A problem with simplifying libpng configuration is that some
>> applications excessively use libpng configuration options in their
>> implementation.  GraphicsMagick's png/mng support may match that
>> description.
>
>
> I'm suggesting simplifying the API.  In this case I can see that the default configure configuration, the one in scripts/pnglibconf.h.prebuilt,  does not actually provide either ARM_NEON_CHECK or ARM_NEON_API.  The PowerPC hardware optimizations do provide an on/off API but I don't think Intel or MIPS do.

Random libpng users thanked me when I told them that I do not plan to
remove libpng APIs and break their apps. Not without a judicious
deprecation plan, and not without a reasonable guarantee that the API
that does get removed is indeed guaranteed to be no longer used.

Case in point: the "push" reader (i.e. pngpread). That was used by web
browsers (Mozilla, WebKit, Chromium, etc.); but now, thanks to the
simplified image reader, the "push" reader is reasonably believed to
be not used anymore and thus can be removed.

What we do need is better testing to guarantee the stability of our API.

The upgrade from libpng-1.2 (with the all-visible pngstruct) to
libpng-1.5 and libpng-1.6 (with that structure removed, after a
way-too-short deprecation interval in libpng-1.4) was a bit traumatic,
most notably, with Debian. Lots of apps got broken, and it took them
many years either bringing them up to date or having them removed from
the Debian distribution.

> Look at TurboJPEG for an example of a similar change.  TurboJPEG makes it very easy to read whole JPEG files at once, but it also adds the ability to do 90 degree rotations in one operation; so the new API is simpler than the original IJG API but it also gets a really useful addition.

That is a good example, as *another* library (TurboJPEG) having
simpler and higher-level API besides the lower-level IJG API.

I would have no problem with *another* png-processing library (let's
call it "TurboPNG") having a simpler and higher-level API *besides*
libpng.

<confession> I started rewriting OptiPNG in C++17 </confession>

But on the other hand, I very strongly oppose breaking the libpng API
and, indirectly, most (if not all) the apps written during the last
quarter century.

> I think I'm about to become a badly scratched record; delete them all (not VS, not configure, your choice on CMake), see who whines.

I am ok with deleting functionality that's known to be broken and thus
reasonably expected to not be used. But I am not ok at all with
hurting libpng users and their apps who depend on functionality that's
injudiciously removed, and then waiting and seeing which ones of them
whine because they're hurt.

Sincerely,
Cosmin