[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was R
From: |
Arthur Miller |
Subject: |
Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets) |
Date: |
Sun, 29 Nov 2020 01:22:18 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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 :-).
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), (continued)
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Akira Kyle, 2020/11/23
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Lars Ingebrigtsen, 2020/11/24
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Akira Kyle, 2020/11/24
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Eli Zaretskii, 2020/11/25
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Akira Kyle, 2020/11/27
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Eli Zaretskii, 2020/11/28
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Arthur Miller, 2020/11/28
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Eli Zaretskii, 2020/11/28
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets),
Arthur Miller <=
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Akira Kyle, 2020/11/28
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), martin rudalics, 2020/11/29
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Eli Zaretskii, 2020/11/29
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Akira Kyle, 2020/11/29
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Eli Zaretskii, 2020/11/30
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Akira Kyle, 2020/11/30
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Eli Zaretskii, 2020/11/30
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Akira Kyle, 2020/11/30
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), martin rudalics, 2020/11/30
- Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets), Eli Zaretskii, 2020/11/30