Re: Interest in nt_load_image?

[Juan José García-Ripoll]

Eli Zaretskii <address@hidden> writes:

>> From: Juan José García-Ripoll
>>  <address@hidden>
>> 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.

Not really. tool-bar.el uses find-image which can be trivially extended
to also seach for PNG as last resort. This is what I showed in my
previous message with a screenshot.

Also I am just trying to address Phillip's complaint about keeping track
of the dependencies. I agree that having to manually download and copy
libxpm-nox.dll is just one more complication that, in the Windows case,
is not needed. This would also make the *-no-deps.zip file only
dependent on libgmp.dll and nothing else.

diff --git a/lisp/tool-bar.el b/lisp/tool-bar.el
index 7df1e28..d0aef3d 100644
--- a/lisp/tool-bar.el
+++ b/lisp/tool-bar.el
@@ -150,16 +150,20 @@ tool-bar--image-expression
         (xpm-spec (list :type 'xpm :file (concat icon ".xpm")))
         (xpm-lo-spec (list :type 'xpm :file
                            (concat "low-color/" icon ".xpm")))
+        (png-lo-spec (list :type 'png :file
+                           (concat "low-color/" icon ".png")))
         (pbm-spec (append (list :type 'pbm :file
                                  (concat icon ".pbm")) colors))
         (xbm-spec (append (list :type 'xbm :file
-                                 (concat icon ".xbm")) colors)))
+                                 (concat icon ".xbm")) colors))
+        (png-spec (append (list :type 'png :file
+                                 (concat icon ".png")) colors)))
     `(find-image (cond ((not (display-color-p))
                        ',(list pbm-spec xbm-spec xpm-lo-spec xpm-spec))
                       ((< (display-color-cells) 256)
-                       ',(list xpm-lo-spec xpm-spec pbm-spec xbm-spec))
+                       ',(list xpm-lo-spec png-lo-spec xpm-spec png-spec 
pbm-spec xbm-spec))
                       (t
-                       ',(list xpm-spec pbm-spec xbm-spec))))))
+                       ',(list xpm-spec png-spec pbm-spec xbm-spec))))))


>> 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.

I believe this executable cannot be built in older versions, as msys does not
even support Windows XP. It pobably also does not run there. What would you use
to build it? Are there any regression tests for those platforms?

>> >> +  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?

You assume too much of me. I do not know what is going on there under the
hoods. And your question also applies to the code in image.c that uses this
exact piece of code, and which is in the non-platform-dependent part (HAVE_PNG
section).

> 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.

My motivation on this particular contribution is not space, but removing
external dependencies and making the code more robust. Building the Windows
port around GDI+ makes it also more future proof: if GDI+ support is dropped in
the near future (which I doubt, given it is also supported by Direct2D), it can
be almost trivially replaced with Windows Image Component, which is the more
modern interface.

Cheers,

P.S.: Just a side question, is LCMS2 actually used anywhere in Emacs?

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es