Re: Emacs canvas support

[Eli Zaretskii]

> From: David Engster <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 29 Apr 2020 21:23:30 +0200
> 
> > AFAIU, Meld seems to draw the graphics _between_ windows, and only
> > highlights the source lines with background colors.  I think we can do
> > that if we use an extra window in-between the two being compared, and
> > put images in that extra window to show the graphical description of
> > the changes between the two versions.
> 
> I actually tried exactly that, many years ago. I dimly remember that
> handling the coordinates was pretty complicated and it was slow. Like,
> orders of magnitude too slow, even with the simplest and fastest image
> types. There was no way you would ever be able to scroll text and update
> the diff visualization alongside it. It was just a flickery mess. It
> would of course be possible to visualize the diff in an idle timer and
> not during scrolling, but that is exactly what I mean above with "not
> really satisfactory", so I gave up.

Hmm... yes, I see your point.  We'd need to find a way of somehow
synchronizing the windows, which is not very easy (witness
follow-mode).

> > Drawing over normal text, if we don't want to redesign the entire
> > display engine, needs some new kind of "display element" ( a sibling
> > to "character", "image", "stretch", etc.), one that doesn't
> > necessarily have any effect on the metrics of the screen lines it is
> > drawn upon.  I'm not sure I have a clear idea about what features such
> > a drawing will need to support, but it could be possible to add such
> > an element with not too much effort.  Would someone want to come up
> > with a reasonable list of requirements for such a feature?
> 
> When I played around with it, I thought a first iteration could be to
> simply expose the basic Cairo API to ELisp, which is essentially drawing
> lines/arcs/rectangles and filling. I thought that maybe it would be
> possible that one could handle this like a graphical transparent
> overlay, but I'm afraid I'm way out of my depth here. I have no idea how
> one would handle scrolling, for instance.

Right, the main problem is not how to draw, but how to tell the
display engine where's the drawing on the screen, and when to redraw
it.