Re: Interest in nt_load_image?

[Eli Zaretskii <eliz@gnu.org>]

> From: Juan José García-Ripoll
>  <juanjose.garciaripoll@gmail.com>
> Date: Mon, 30 Mar 2020 16:36:05 +0200
> 
> >> I have also verified that it is possible to convert all *.xpm icons
> >> to *.png format and thus eliminate the need to include
> >> libXpm-noX.dll. Plus, the size of the icons is reduced by 50%
> >
> > We aren't going to get rid of XPM icons in the distribution any time
> > soon (because of other platforms), so I don't see an urgent need to do
> > this.
> 
> No. I did not mean to replace the xpm icons in the sources, but instead
> distribute emacs without depending on libxpm-nox, at least on Windows.

At 84KB, I don't see how the XPM DLL could be a problem for anyone.
More importantly, tool-bar.el explicitly loads XPM icons.

> However, regarding "ancient" windows machines, GDI+ was introduced in
> Windows XP and Windows 2000
> (https://docs.microsoft.com/en-us/windows/win32/gdiplus/-gdiplus-gdi-start). It
> hardly gets older than this with working machines, does it? You would
> have to go back to Windows 98 or NT 4.0, whose support ended 17 years ago.

I know.  Believe it or not, we do still support those old version (or
at least try not to break their support knowingly).  You will see that
in many places in the w32-specific code, for example we load
unicows.dll and call MultiByteToWideChar through a function pointer.

> >> +  if (STRINGP (specified_bg)
> >> +      ? FRAME_TERMINAL (f)->defined_color_hook (f,
> >> +                                                SSDATA (specified_bg),
> >> +                                                &color,
> >> +                                                false,
> >> +                                                false)
> >> +      : (FRAME_TERMINAL (f)->query_frame_background_color (f, &color),
> >> +         true))
> >
> > Do we really need to go through the hook mechanism here?  The frame
> > type is known in advance, right?
> 
> This code is not testing for frame type, but whether the background was
> specified as an argument for image creation (uses the given value), or
> not (it then uses ->query_frame_background). I just copied this form
> image.c, which is where the determination of the PNG background color
> takes place when libpng is used.

image.c is mostly platform-independent code, but this isn't: the
result of

   FRAME_TERMINAL (f)->defined_color_hook

and its ilk, i.e. what functions will be called, is known in advance.
Why not call those functions directly?

> The good thing about this is that using Windows native components must
> be faster than going through third-party libraries and this would allow
> distributing a *-no-deps.zip with support for most standard bitmap
> formats.
> 
> The bummer is that there is no simple replacement for rsvg yet, and this
> library by itself pulls in libpng, libjpeg, libgif, libtiff, cairo, ...

I'm not really bothered by additional dependencies or by the disk
space they take.  My main motivation is to give users more options and
features to use, because I'm quite sure the results will not be
identical, so sometimes one method will be preferable, and sometimes
the other.  This makes Emacs more future-proof, which on a platform
such as MS-Windows is no small feat.