From: Eli Zaretskii <eliz@gnu.org>
To: "Juan José García-Ripoll" <juanjose.garciaripoll@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Interest in nt_load_image?
Date: Mon, 30 Mar 2020 18:50:50 +0300 [thread overview]
Message-ID: <83v9ml3kpx.fsf@gnu.org> (raw)
In-Reply-To: <86lfnhsyei.fsf@csic.es> (juanjose.garciaripoll@gmail.com)
> 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.
next prev parent reply other threads:[~2020-03-30 15:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-29 19:33 Interest in nt_load_image? Juan José García-Ripoll
2020-03-29 21:55 ` Juan José García-Ripoll
2020-03-30 2:21 ` Eli Zaretskii
2020-03-30 7:54 ` Juan José García-Ripoll
2020-03-30 13:46 ` Eli Zaretskii
2020-03-30 14:36 ` Juan José García-Ripoll
2020-03-30 14:44 ` Juan José García-Ripoll
2020-03-30 15:50 ` Eli Zaretskii [this message]
2020-03-30 16:15 ` Juan José García-Ripoll
2020-03-30 16:37 ` Eli Zaretskii
2020-03-30 17:16 ` Stefan Monnier
2020-03-30 18:32 ` Eli Zaretskii
2020-03-30 18:41 ` Stefan Monnier
2020-03-30 18:57 ` Eli Zaretskii
2020-03-30 19:39 ` Stefan Monnier
2020-03-31 14:19 ` Eli Zaretskii
2020-03-30 18:06 ` Juan José García-Ripoll
2020-03-30 18:47 ` Eli Zaretskii
2020-03-30 18:53 ` Eli Zaretskii
2020-03-30 23:21 ` Juanma Barranquero
2020-03-31 8:01 ` Juan José García-Ripoll
2020-03-31 13:14 ` Juanma Barranquero
2020-03-31 14:50 ` Stefan Monnier
2020-03-31 15:25 ` Juanma Barranquero
2020-03-31 16:54 ` Stefan Monnier
2020-03-31 15:13 ` Juan José García-Ripoll
2020-03-31 15:28 ` Juanma Barranquero
2020-03-31 13:31 ` Eli Zaretskii
2020-03-30 15:14 ` Stefan Monnier
2020-03-30 15:57 ` Eli Zaretskii
2020-03-30 17:10 ` Stefan Monnier
2020-03-30 18:23 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83v9ml3kpx.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=juanjose.garciaripoll@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).