Re: Rethinking the design of xwidgets

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Akira Kyle <ak@akirakyle.com>,  emacs-devel@gnu.org
>> Date: Wed, 14 Oct 2020 17:04:07 +0200
>> 
>> 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.
>
> I believe this should be the job of the GUI library we use (Xlib etc.)

Yes, of course. EGL is your library :-)

I am thinking more in terms of performance and simplification of
implementation. Egl runs on major OS:s + android, and opengl is very
platform independent, so one code path (mostly) on all 3 major platforms
(hopefully). Also traditional Xlib and GDI does not hardware accelerate
everything or specially well. There is some article on msdn about
Direct2D and GDI for example, different driver paths etc. They have
exposed Direct2D for applications for performance reasons, as they state
GDI renders large portions through CPU in kernel mode, while DX2D is in
user space etc. I believe Xlib is even worse in that regard. Also future
of Xlib seems a tad bit uncertain. OpenGL via EGL could be Emacs's
"directx2d". Wayland uses egl and I am correct sdl uses it as well.
Maybe Emacs could use sdl to render too, but I think it would be
unnecessary expensive in term of complexity.

>> But Emacs will maybe run on some slow devices (atmel Emacs anyone?), so
>> you probably don't want to ditch away all that disp stuff.
>
> Different Emacs configurations could employ different redisplay
> optimizations, if we know which ones are necessary when.
>
>> > We try not to use machine-dependent code in Emacs, because that's a
>> > maintenance burden, what with today's fast pace of chip development
>> > and obsolescence.  Vectorization is generally left to optimizing
>> > compilers, and relying on special hardware, such as GPU, is not
>> > something we should depend on directly.  We should instead hope that
>> > the GUI toolkits and display systems we use will do that for us.
>> Would it be considered too machine-dependent if you rendered into
>> off-screen OpenGL surface as your rendering target? Should be avialable
>> on Nvidia/AMD/Intels gpus. With offscreen egl you would have relatively
>> OS independent code too; but that would require explicit linking to
>> proprietary libs. I mean X11/Win32 already does that when proprietary
>> drivers are installed, so Emacs (and any other software) "implicitly"
>> links to those, but I don't how it is viewed if you would to explicitly
>> when present.
>
> Why should we do that in our own code, as opposed to using some
> higher-level library?
Didn't you disliked proposal to use libCurl with answer that it would make
Emacs dependent on yet another library? :-)

Cairo is a nice 2D api, and has opengl backend too. I dont' know how
effective the backend is, but sure it could work. I dislike all the
dependencies it pulls in, but in a typical GNU/Linux system they are
anyway installed. Can you divorce it from Gtk requirement? Or it is
already possible to use Cairo in Emacs without rest of Gtk?

I proposed egl, as a platform independent surface drawing that enables
use of OpenGL. Someone might one day create a scene graph (isnt't it
just a list of lists) and maybe do some cool stuff in ELisp that we are
not really thinking of now.