From: Po Lu <luangruo@yahoo.com>
To: xenodasein@tutanota.de
Cc: "Björn Bidar" <bjorn.bidar@thaodan.de>, emacs-devel@gnu.org
Subject: Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning
Date: Wed, 30 Nov 2022 21:37:52 +0800 [thread overview]
Message-ID: <878rjsv9zj.fsf@yahoo.com> (raw)
In-Reply-To: <NI7N4J4--3-9@tutanota.de> (xenodasein@tutanota.de's message of "Wed, 30 Nov 2022 12:51:07 +0100 (CET)")
xenodasein@tutanota.de writes:
> First of all thank you for not going straight for it's not possible /
> no one would want that / it's the wrong way / etc.
I only say that when it really is impossible, or wrong. I see nothing
wrong in principle with making the PGTK build work well on X, but
whoever tries is in for a lot of pain, so I'm not volunteering.
> I tried to suggest last year a way to draw your own window content
> without GTK, Lars said great you can start from vanilla X build,
> you and Eli on the other hand gave the impression that you found it
> extremely undesirable. Which brings me to the point that this seems
> like a question of what do you want done instead of how to. I am
> myself not at the point where I could pull this off alone, but I'm
> getting there. Others would attempt at things like that if they found
> any enthusiasm about I'm sure.
I've already explained why doing all graphics in Emacs will be a major
step backwards. But let me reiterate:
- it will not work well with X, especially not over slow network
connections, because the only way to do that without special-casing
X is to fedex the local back buffer contents to the X server every
time something changes.
- we will end up having to write a huge amount of code. At least one
set of code for each kind of graphics device: pseudo-color,
static-color, and true-color. And probably different sets of code
every combination of pixmap format and visual.
Each set of code will at least have to include, aside from
trapezoid, line and arc rasterization, the ability to apply more or
less arbitrary transformations to images, and alpha blending.
All the code will need to be fast, which will be impossible to do
portably: the best case on X is that the shared memory extension is
usable, which will let Emacs avoid uploading huge amounts of image
data to the X server upon each change. The X server will still have
to upload the shared memory to graphics memory every time Emacs
tries to copy from the shared memory to the window, as it cannot
know which parts of the shared memory has changed since the last
upload.
- it will not make Emacs more portable, because the vast majority of
the complicated window system code involves interactions with the
window system itself, and not computer graphics. How do you propose
to make, for example, xselect.c, portable, when the X selection API
is fundamentally different from the clipboards or pasteboards found
on different systems and exposed by toolkits, and Emacs has always
exposed a very low level interface to Lisp via
`selection-converter-alist', `x-get-selection', and related
functions and variables?
> You must keep in mind that big contributions like this must have a
> foundation if there will be any hope of them even happening.
``this'' being?
> For example I can almost imagine the answers if I suggested separating
> some translation units instead of using #ifdef's every five lines, so
> I won't don't worry.
[...]
> Or take as example the recent discussion on macros. It won't make
> much of a difference indeed if some line is a function or a macro,
> issue is the resistance to even simple changes like that; it implies
> the impossibility of something not as simple.
No, it does not. What you're saying is that every time someone suggests
a change to Emacs, we should agree to it, even if the change is
absolutely pointless or even wrong.
The problem with that theory is self evident.
> I remember Eli requesting not to change the location of some function
> on the grounds that it will now be harder to find where it is.
Which is bad because..?
> So what is my point, when some person asks why do I need to binaries,
> instead of saying things like "why not" say we need more people to
> work with C parts, that's all.
What's the verb ``binaries''?
next prev parent reply other threads:[~2022-11-30 13:37 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-26 22:38 Questions regarding PGTK, high-dpi font-rendering, new X11-Warning Björn Bidar
2022-11-27 0:48 ` Po Lu
2022-11-28 0:09 ` Björn Bidar
2022-11-28 1:17 ` Po Lu
2022-11-28 8:44 ` Björn Bidar
2022-11-28 11:41 ` Po Lu
2022-11-30 9:27 ` xenodasein--- via Emacs development discussions.
2022-11-30 10:13 ` Po Lu
2022-11-30 12:50 ` Stefan Monnier
2022-11-30 13:39 ` Po Lu
2022-11-30 16:50 ` Stefan Monnier
2022-12-01 0:52 ` Po Lu
2022-12-01 0:56 ` Stefan Monnier
2022-12-01 2:38 ` Po Lu
2022-12-01 5:24 ` Stefan Monnier
2022-12-01 6:45 ` Po Lu
2022-12-05 20:01 ` chad
2022-12-06 11:39 ` Po Lu
2022-12-06 13:05 ` xenodasein--- via Emacs development discussions.
2022-12-06 13:24 ` Po Lu
2022-12-01 10:25 ` Manuel Giraud
2022-12-01 12:44 ` Visuwesh
[not found] ` <87cz94vjgl.fsf@yahoo.com-NI70zP3----9>
2022-11-30 11:51 ` xenodasein--- via Emacs development discussions.
2022-11-30 13:37 ` Po Lu [this message]
2022-11-30 14:00 ` xenodasein--- via Emacs development discussions.
2022-11-30 14:09 ` Po Lu
2022-11-30 15:51 ` xenodasein--- via Emacs development discussions.
2022-12-01 0:49 ` Po Lu
2022-11-30 16:23 ` Eli Zaretskii
2022-11-30 16:56 ` xenodasein--- via Emacs development discussions.
2022-11-30 17:43 ` Eli Zaretskii
2022-12-12 23:52 ` Björn Bidar
2022-12-13 1:22 ` Po Lu
-- strict thread matches above, loose matches on Subject: below --
2022-11-29 6:33 Pedro Andres Aranda Gutierrez
2022-11-29 6:43 ` Po Lu
2022-11-29 9:36 ` Björn Bidar
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=878rjsv9zj.fsf@yahoo.com \
--to=luangruo@yahoo.com \
--cc=bjorn.bidar@thaodan.de \
--cc=emacs-devel@gnu.org \
--cc=xenodasein@tutanota.de \
/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).