emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optional support for GDI+ on Windows (emacs-28)


From: Eli Zaretskii
Subject: Re: Optional support for GDI+ on Windows (emacs-28)
Date: Wed, 01 Apr 2020 18:45:34 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 01 Apr 2020 10:58:29 -0400
> 
> > I didn't request anything that could be qualified as jumping through
> > hoops.  This is our standard implementation paradigm for optional
> > features on MS-Windows, you can see it all over the place in w32*.c
> > files.  Convenience macros are available to make coding this
> > more-or-less copy-pasting from some other similar feature.
> 
> I don't think "variables to control whether <foo> is used for each
> supported <bar>" is comparable to what we do for other
> "optional" features on MS-Windows.

Actually, it is comparable.  See w32-unicode-filenames, as one
example.  Another example is the font-backend frame parameter, which
controls what shaping engine will be loaded and used.

> Also, for "optional features on MS-Windows", the usual behavior if the
> lib is not available at run-time is just not to provide the
> corresponding functionality, rather than to fallback on some alternative
> C implementation.

In most cases, but not all of them.  See above.

> IOW, I think what would be comparable is: build with support for GDI+
> images only (i.e. without support for images via libpng and friends),
> and make sure Emacs does run even if GDI+ is not available (simply with
> the limitation that it can't display those images, just like what we
> have now if libpng is not available at run time).

I don't think it is correct for us to commit ourselves to GDI+ right
now.  We should first see if it is a 100% capable replacement, and
learn about its advantages and disadvantages.  We always do that with
new optional features: they start disabled.

In this case, we should also consider whether GDI+ will be supported
long enough before MS comes up with the next buzzword and decides to
deprecate GDI+ (something that happened with Uniscribe, for example).
This dependence on MS whims is one significant disadvantage of using
the native capabilities where ports from Posix are available as
replacements.

So, by and large, I don't think it's reasonable to rush to GDI+
without collecting experience first, and having those optional knobs
is necessary for that.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]