Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Arthur Miller]

Tomas Hlavaty <tom@logand.com> writes:

> On Wed 02 Dec 2020 at 17:24, Akira Kyle <akira@akirakyle.com> wrote:
>> On Tue, Dec 01, 2020 at 12:44 AM, Tomas Hlavaty <tom@logand.com> 
>> wrote:
>>
>>> On Mon 30 Nov 2020 at 10:03, Akira Kyle <akira@akirakyle.com> 
>>> wrote:
>>>> and because I see pgtk as the future of Emacs on GNU/Linux systems
>>>> as X becomes increasingly obsolete.
>>>
>>> I am not sure such future is bright.
>>>
>>> In that future, is there no way to do graphics without a widget 
>>> toolkit?
>>
>> Sure there is. Under wayland you can just dump pixels into a 
>> shared buffer to render them to the screen or use EGL to render 
>> using a GPU. The difference from X is that wayland offers no 
>> convince functions to actually draw pixels into such a buffer, its 
>> up to the client to do so. In order to not reinvent the wheel, its 
>> much more convenient to use a toolkit to draw the elements it's 
>> good at drawing.
>
> "just dump pixels" and "no function to actually do that" and "use
> toolkit" does seem to contradict the point of being able to do it
> without toolkit.
>
> How long will pgtk future last?

> Compare that kind of future with for example ansi terminal future.
> Which one do you think has longer future ahead?  Why?
I don't think you are askinkg for ANSI terminal; I think you are asking
for Emacs on framebuffer. 

I don't know how hard it is to create it, but it is probably on same
level as concole/terminal backend, X11 backend, Win32, Gtk, etc. I don't
know, I never used framebuffer so I can't really tell; just a sense.

>>>> AFAIU the pgtk version, like the ns version it was modeled after,
>>>> doesn't implement everything in the main frame area of Emacs as
>>>> widgets, only the tool and menu bars are implemented as proper
>>>> widgets.
>>>
>>> Also popup menus that pop up on a mouse click are gtk iirc.
>>>
>> I think it would be possible to implement such menus without GTK using
>> just child frames.
I agree with you on that one. I played with the idea; if you search the
archive you will find some poorman menu I sent in pga bug with focus
with child frames. Emacs already does halv of the jobb; one can display
a text buffer, enable current line highlight and set special text properties
and there is a simulated menu; sort of. 

> Would not it be better to extend the canvas idea you mentioned above to
> allow graphics in general, portable, toolkit independent way?
svg renderer is; as I understand. Maybe I am wrong, but as it seems
Emacs has got a built-in graphics via svg. I always thought Emacs went
through external application to display svg, but I learned recently it
does not.

Other path is to use Vulkan or OpenGL; I think OpenGL is better choice
for Emacs; you can render to a texture in memory, and handle XImage or
XPixmap to Emacs (hopefully - I haven't had time yet to go through and
test Eli's kind walkthrough yet). You could actually render entire emacs
buffers via egl to textures and display them via framebuffer. I don't
think it would be easy, but possible. Would require lots of C coding; if
you have time for that :-).