Re: Rethinking the design of xwidgets

[Arthur Miller <arthur.miller@live.com>]

Aiko Kyle <aikokyle@gmail.com> writes:

> 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.
AFAIK OpenGL runs on more systems then Emacs, and is considered as
probably THE easiest graphics API out there (Turtle graphics probably
being easier :-)).

It is superseeded by Vulkan, but Vulkan is probably too much for an
application like Emacs in terms of complexity vs benefit. 

> 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,
In my world, Emacs would be better shying away from big GUI toolkits and
ginormous dependencies.

Emacs window is (logically) one giant glorified tty in principle; tucked
into an OS window and Emacs does it's own redisplay of the major os
window area, so GUI toolkits are really just placeholders for Emacs to
render. Buttons, menus, toolbars can all be implemented by Emacs buffers
rendered as Frames, or Windows. Does not blend very well into Gnome or
KDE world, but with some styling might be pretty too look at anyway.

As I udnerstand Emacs now does it's own
font and text rendering via Freetype , so question is if needs Gtk at
all more then being pretty on Gnome desktops? Maybe Cairo alone is not
bad, since it can be used as graphics API to render to and there are
also hardware accelerated versions via opengl bindings (look in Mesa source).