Re: Emacs canvas support

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 29 Apr 2020 21:19:51 -0400
> 
> I think it would make more sense to treat the overlaid canvas as
> a completely separate pixmap: when we get an request to redraw
> a particular area of the screen, we'd ask the current redisplay code to
> redraw the corresponding text content and then we'd ask the canvas code
> to draw on top of it.

Unfortunately, most redisplay cycles don't start from a request to
redraw a particular area of the screen.  This only happens when we get
expose events from the WM, which is not the "normal" trigger of
redisplay.  Usually, redisplay is entered when Emacs is idle, and it's
one of the display engine's main jobs to figure out what parts of
which windows need to be redrawn, by just considering the changes in
buffer text, their properties/overlays, and window geometry and
starting point.  In doing so, the display engine need to know, up
front, which parts of the display reside where on the screen, whether
any of them needs to be redrawn because the underlying Lisp data was
modified by some command since the last redisplay.

So AFAIU it won't work to redraw the "canvas" only when the text
beneath it changes; the display engine needs to be able to redraw the
canvas itself even if the text didn't change, and it needs to know
which portions of the window are affected by the canvas in order to
make decisions regarding how to redraw the window optimally.