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

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Akira Kyle <akira@akirakyle.com>,  larsi@gnus.org,  emacs-devel@gnu.org
>> Date: Sat, 28 Nov 2020 09:57:39 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > As long as the widget can be told to use a given rectangular portion
>> > of the screen, we should be fine: the current Emacs display engine is
>> > perfectly capable of handling display elements that occupy an area of
>> > certain dimensions.
>> 
>> How can I tell any drawing routines to use certain rectangular area on
>> display so it is in harmony with Emacs display engine?
>
> On the display engine level, you need to define a new kind of "display
> element" (see 'enum glyph_type' in dispextern.h) and new kind of
> method for producing such a display element (see 'enum it_method' in
> dispextern.h).  You will also need to write a BUILD_<FOO>_GLYPH_STRING
> macro that produces a "glyph string" from one or more display elements
> of this new type; see BUILD_XWIDGET_GLYPH_STRING in xdisp.c as an
> example.  Glyph strings are the interface between xdisp.c, which
> parses buffers and strings for display and performs display layout,
> and xterm.c (see below) which actually draws the resulting display
> elements.
>
> On the Lisp level, you will probably use a special 'display' property
> whose value specifies the widget with the necessary parameters, like
> we do with images.
>
>> Are there callbacks I can connect too if I would like to update opengl
>> viewport that I can hook easily into? Where do I look? I am not sure I
>> understand it from image.c; it was there I was looking. I never looked
>> into xwidgets though. Can be just me; but if you can point me to right
>> place to look at I am thankful. 
>
> The actual drawing is in xterm.c (for X; it's w32term.c for
> MS-Windows, nsterm.m for NS, and term.c for TTY frames).  Each type of
> display element has a function there, which is called to draw the
> display element.  For example, x_draw_image_glyph_string for drawing
> images.  You will need to write a new function for this new display
> element, whose parameters are passed from the new it_method method
> above.  Not sure if this is what you meant by "callback to connect to
> in order to update opengl viewport".
>
> (image.c just prepares the data required for drawing an image; its
> functions are not called when drawing the image, we just use the
> pixmap produced by image.c and various other parameters, like image
> dimensions etc.)
Thank you for the kind tour! This was much more then I was hoping for :-).