Re: Motif support

[Akira Kyle]

On Mon, Dec 20, 2021 at 9:54 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> I do know how the display code works and how it evolved, but frankly I
> don't understand what you are trying to say, concretely.  I understand
> the vague thoughts and ideas of the technological advances in GUI vs
> the development of the Emacs display, but do you actually have
> something specific to suggest about that, like what could the Emacs
> display engine do differently using some of these technologies?
> because I think we all understand the general issues; it's specific
> practical ideas that are missing, if we really want to modernize the
> Emacs display code.
>

Sorry I don't have much to offer besides vague thoughts as I'm not an
expert in emacs' display code nor computer graphics in general, I was
more hoping it might prompt those who are experts to comment. Perhaps
the answer is, as Stefan suggested, that the largest slowness in
emacs' display is due to elisp, which has inherent difficulties in
being parallelized. I think, though, that it's probably best to
profile emacs' display to really understand what the bottlenecks are
before thinking about how things could be done more efficiently, and
often there are different approaches to parallelizing code that one
cannot a priori decide which will be the optimal. My cursory
understanding of the servo project is that they would often
implemented several different parallel approaches to see which ones
worked best in practice.

> And even if you are talking about a complete redesign of the display
> engine, then again, to make that even marginally practical, please
> present specific ideas of such a redesign.  That at least could give
> someone motivation to sit down and develop those ideas at some point.

I think the complexity of the current display code is a huge barrier
to this type of experimentation and I wonder if there would be a
cleaner abstraction for the various toolkits emacs can use than the
current "redisplay_interface" struct which if I understand correctly,
is the main way emacs currently abstracts each toolkit.

> > Sure, but the question isn't a binary one (hardware accelerated vs
> > not) but how well is the available hardware being utilized which is a
> > much more difficult question to answer.
>
> The question that interests me is which part(s) of the Emacs display
> code you'd like to accelerate using this hardware.