Re: Rethinking the design of xwidgets

[Aiko Kyle <aikokyle@gmail.com>]

Replying to both Stefan's and Eli's reply to Arthur

On Wed, Oct 14, 2020 at 09:04 AM, Arthur Miller 
<arthur.miller@live.com> wrote:

>> In case where there is a discret gfx card (i.e. Nvidia/AMD) it 
>> is
>> probably faster to send everything to GPU and ask it to render 
>> a 
>> giant texture and then use it as XWindow pixmap, or something 
>> similar
>> then to figure out on CPU all the stuff that should not be 
>> displayed.

On Wed, Oct 14, 2020 at 10:53 AM, Stefan Monnier 
<monnier@iro.umontreal.ca> wrote:

> I think it's much harder than it sounds: most of the work needs 
> access
> to data structures that aren't friendly to GPUs, so the work of
> providing data to a GPU in an appropriate form would probably 
> not be
> much more less in most cases than the drawing itself.
>
> (talking-about-things-one-does-not-understand-mode 1)
>
> But indeed, maybe we could split the "drawing" from the glyph 
> matrices
> to the glass into a first step that draws into a "pixmap matrix" 
> and
> a second step that draws from it onto the glass.  This should 
> make it
> unnecessary to try and "scroll" (parts of) the display since it 
> should
> be "just as fast" to copy from the pixmap matrix as it is to 
> copy from
> the current glass's content.
>
> (talking-about-things-one-does-not-understand-mode -1)
>
> I think the performance of the redisplay is by and large poorly
> understood.  While there are known cases where people experience 
> "slow
> redisplay" it's usually very unclear what that means concretely.
> In many cases this can be completely unrelated to the actual 
> redisplay
> code (e.g. the time is spent running some expensive code off of
> `post-command-hook` or font-lock or younameit).
>

On Wed, Oct 14, 2020 at 09:32 AM, Eli Zaretskii <eliz@gnu.org> 
wrote:

> I believe this should be the job of the GUI library we use (Xlib 
> etc.)


As someone who has done a little bit of GPU programming, I think 
Emacs should stay as far away from needing to care about the 
architecture and optimization for GPUs as possible. It is hard and 
very non-portable. I should have clarified in my prior email that 
I really meant that Emacs could take advantage of newer hardware 
like GPUs and other SIMD vectorization units not directly because 
it is a huge PITA to work with, but through appropriate high level 
libraries. I don't think Emacs should be in the business of trying 
to actually draw primitives like lines and rectangles onto the 
glass directly whether through the frambuffer or low level gpu 
primitives like opengl. It requires specific expertise to get 
right and do efficiently that I think is beyond the scope of Emacs 
development.

Since Emacs already has its own internal abstraction for actually 
doing the drawing through the redisplay_interface, my point was 
more that Emacs should gain hardware acceleration by ensuring the 
GUI toolkits it uses take advantage of such features. I think gtk 
4 will have even more integration with hardware acceleration, and 
Emacs is better served by making the redisplay_interface 
abstraction cleaner. The Emacs pgtk port I think is a big step in 
that direction [1] and I really hope they get it in a feature 
branch here soon. Someone in the remacs project even made an Emacs 
backend to Mozilla's webrender [2] which was created with hardware 
acceleration at its core. I think too much of Emacs' current 
display design is influenced by Xlib which wasn't designed with 
such hardware acceleration in mind and this is what is currently 
limiting Emacs taking advantage of the hardware acceleration 
advances in the toolkits it uses. I think my comment on another 
Email in this thread about the current way Emacs uses librsvg on 
gtk+cairo builds illustrates this point.

Improving the redisplay_interface abstraction might then allow the 
toolkit backend to disable certain redisplay optimizations that 
are unnecessary for good performance with that toolkit and that 
may be better handled inside the toolkit than inside Emacs.

[1] https://github.com/masm11/emacs/pull/23
[2] https://github.com/remacs/remacs/pull/1581