Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Po Lu]

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''?