Re: GDI+ take 3

[Eli Zaretskii <eliz@gnu.org>]

> From: Juan José García-Ripoll
>  <juanjose.garciaripoll@gmail.com>
> Date: Sun, 19 Apr 2020 22:28:24 +0200
> 
> Two minor changes attached. First, the introduction of the Qnative_image
> type makes one call to image_can_use_native_api irrelevant.

That makes some assumptions I felt uneasy about.  First, it assumes
that the native_image entry will never have an init method; this could
become wrong at some future point, at which time someone will have to
remember to adapt initialize_image_type to handle that (since
native_image doesn't really have a library to load).

Second, what happens if the TYPE argument specifies an image type the
native_image cannot handle (e.g., SVG), and the corresponding optional
image library is not linked in or is unavailable at run time?  With
your patch, we would return true, right?

So, all things considered, I think it is more future-proof to leave
that call in place, at least until we make up our minds regarding the
default configuration on MS-Windows.

> Regarding this, I think it is a bad idea to introduce Qnative_image,
> because that is not an image format and users cannot recognize the
> actual image type from the image descriptor.

I'm not sure I understand the issue.  When you say "users", what do
you mean in this context?  If you mean users like me and you, then how
and where would we see Qnative_image?

The technical reason I introduced Qnative_image is that look
up_image_type wants to return a struct, and its callers depend on
that.  Also, I thought about the use case where none of the optional
image libraries are compiled in, in which case this will be the only
element of that array.  I shortly entertained the idea to put the
requested image symbol (like Qpng etc.) there, but I didn't like the
idea of changing a const struct.

What would you propose to do instead?

> The second fix makes w32image.c behave like nsimage.c, in that a delay=0
> is regarded as non-existant, thus returning nil. This makes animations
> default to the minimum animation delay, which currently is 0.01, and
> more useful than a delay of 0.

You are right.  However, I believe I already fixed that, albeit a bit
differently, as part of commit 423089d (after bumping into the same
problem during testing my recent changes).  We can use your change
instead, if you think it is better for some reason.

Thanks.