Re: Emacs canvas support

[Arthur Miller]

Eli Zaretskii <address@hidden> writes:

>> From: Arthur Miller <address@hidden>
>> Date: Thu, 30 Apr 2020 15:11:10 +0200
>> Cc: address@hidden, address@hidden
>> 
>> I have a question here about display: when lisp engine decides to draw
>> the display, how difficult would it be to add a callback for pre- and
>> post render?
>
> I don't think I understand the question.  It is trivial to add a call

I am probably not so clear in my writing, but what I mean is, can it be
impelemnted as a hook/callback, to enter same redisplay machinery
several times. As you described in other mails how redisplay is
figuring out what draw, everything has to come from buffers that are
essentially glyph matrices etc. Whatever entry in that machinery is now,
can't we just have a list of hooks that each call into that machinery?
Normally there would be just one such so Emacs work as it is now, but
user could add one before or after, or several do do some extra drawing.

> to a Lisp function anywhere in Emacs, the question is what thats
> function will be able to do to be useful.
Essentially it would be like layered rendering. Imagine Gimp layers.
Since each hook is drawing it's own stuff it would be like a layer.

For example, if Emacs exposed some graphics stuff like say: draw-this,
fill-that, and if drawing layered, like in post-render, that wouldn't
collide with overlays and other stuff, one could draw over images etc.
Similarly a pre-render could put some graphics and images that appear as
a background below normal buffer text.

> If the called Lisp can do
> anything it wants, then how can it be useful without knowing a whole
> lot about the window layout, and what was just now, or will be in a
> moment, drawn on it, and in which parts?
Each hook woul have it's own associated buffer, which could be same as
current buffer or different one (say an temporary with an image in it).
Redisplay engine can then just do whatever it does now to figure out
that buffer so no changes to redisplay engine. Yes, it would draw in
same pixel coordinates of the window it is drawing on. The only hard
part would be to figure out how to trigger redisplay engine when some of
buffers with associated hooks changes (I think, but I am not
knowledgable enough about implementation details here).

>> Prerender callback could be any user lisp function called
>> that do anything it wants, say draw something on the screen as it owned
>> window itself. Than render engine would it's ordinary rendering drawing
>> just as it does now, pretending that there was nothing already drawn, so
>> it would mean no change at all to current c code for rendering.
>
> So how do we prevent the display engine from blissfully drawing over
> what the pre-render draws?

You don't! It is exactly my point to redraw over stuff. Render should
re-draw over what pre-render has drawn etc.

That way, if a pre-render hook, draws say a buffer with an image in it,
then ordinary buffer can draw it's text over it and image would appear
as a background in final view. 

>> Similarly one call a post-render callback and draw over the already
>> rendered text so user could draw whatever on top of already draw
>> onverlas and what not.
>
> How will the post-render know where it can and where it cannot draw?
> Or even where to draw, for that matter (assuming you want to do
> something more useful than just put the same pixels in the same pixel
> coordinates)?
Actually sometimes, you do want to just put pixels in same pixel
coordinates :-). But anyway, one could draw some lines below/above text
in buffers, rectangles, and so on. Info about where and what
to draw comes well from user code. User's elisp can figure out where and
what to draw by examining the buffer and window with usual elisp we have
now?

> For example, if the window scrolls, wouldn't you want
> the graphics drawn by these pre/post-renderers to move on display as
> well, at least sometimes?  If you do, how can you do that without
> knowing some details about the scroll?
Of course. Wouldn't came out automatically, by redisplay engine as it
already is?

>> It is just how z-buffer works and it would mean z order from pre-render,
>> normal render (as it is now) and post render as implicit z-depths.
>
> AFIU, z-buffer doesn't care to obscure what's displayed below.  is
> this what you have in mind: obscuring the "normal" display with some
> graphics?

No I didn't, I had in mind to redraw stuff, so user can draw below or
above whatever Emacs normally draws.

Yeah sure if user chooses to draw two different text buffers on top of
each other it would be a mess, but I don't think that is an issue
because, normally, probably nobody want's to draw to text files on top
of each other.