Re: Interest in nt_load_image?

[Juan José García-Ripoll]

Hi,

I reply to the more technical comments below. What I sent was not meant
for production: it was the result of four hours of work and digging
through Windows manuals. I was surprised it worked so well with so
little code.

Eli Zaretskii <address@hidden> writes:
> Did you verify using these APIs will allow us to keep using the code
> which processes images at display time?  Will image scaling and
> rotation still work as it does now?  What about masking?

Right now all Windows code works towards creating HBITMAP images. This
code only extends that functionality, using GDI+ as an intermediary to
finally produce an HBITMAP.

The only difference is in the masking of images. The current method does
not override the masking of images. However, just like the NextStep /
OSX port, it skips building a bitmask from alpha channels.

To be more precise, the code in image.c scans the image and creates a
separate bitmask if the alpha channel contains either 0x00 or 0xFF. If
there are intermediate values of alpha (from 0x01 to 0xFE) it relies on
alpha blending from the respective library. I do not understand
why. Maybe efficency?

I am right now trying to see whether this would affect some context,
such as icons in toolbars. However, as I said, the OSX port
(ns_load_image) does not use this dual use and instead relies on the OS
for blending.

>> - At configuration time, it works just as the NextStep (NS) system,
>> disabling the use of libpng, libjpeg, libtiff and libgif when the
>> build system is Mingw.
>
> AFAIU, we will also be able to support EXIF without ImageMagick.

The Windows codec takes care of the image orientation automatically, I
believe; but I have no image in mind I can test with. However if you
want any other more sophisticated handling, such as color spaces, one
might need to use a more modern interface (Windows Image Component).

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

> We cannot do this at compile time, because we still try supporting
> ancient Windows versions where GDI+ is not available.  Moreover, I
> think it's good to let users have the ability to decide dynamically
> which image display capability they want.  It certainly makes sense to
> do that initially, while the GDI+ way is being tested in all kinds of
> real-life use cases.

Understood. I was just submitting a proof-of-concept demonstration. I
will integrate the automated configuration in configure.ac later.

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.

>> +static float
>> +w32_frame_delay(GpBitmap *pBitmap, int frame)
>
> A nit: why 'float' and not 'double'?  'float' causes a minor
> inefficiency, so unless there's a good reason, I'd prefer 'double'.

The use of float comes from ns_load_image.c I guess nobody has audited
that either.

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

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

Cheers,

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