bug#67794: 30.0.50; mouse-face is not respected on SVG images

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   alan@idiocy.org,
>   67794@debbugs.gnu.org
> Date: Wed, 13 Dec 2023 19:24:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Manuel Giraud <manuel@ledu-giraud.fr>
> >> Cc: alan@idiocy.org,  67794@debbugs.gnu.org
> >> Date: Wed, 13 Dec 2023 17:50:08 +0100
> >> 
> >> BTW, do you know why mouse-highlight is this way?  Is it because it
> >> was an afterthought of the display engine or is it because of
> >> performance issues or…?
> >
> > How would you design it instead?
> >
> > I'm not saying that what we have is the only possible design, but I'm
> > curious what alternative design ideas could be used.
> 
> Sorry I do not have an alternative design idea 😅.  It's just that from
> my, obviously limited, point of view the Emacs display engine is a work
> horse that could handled many cases regarding how to display glyphs and
> I was wondering why it was not used for mouse highlight also.

We do use the display engine, just the last part of its processing:
the drawing of glyphs on the glass.

> > Btw, AFAIU the person who at the time decided how this will work is
> > here: it's Gerd (CC'ed).  Maybe he can share his memories about why he
> > ended up with this design.
> 
> Thanks for summoning Gerd.  I have an answer now even though I do not
> have the knowledge to understand it fully.

What Gerd says, in a nutshell, is that since this code was running
from a signal handler, there was a basic requirement to do it as
simple as possible, and in particular not to do anything that would
mean memory allocation, since memory allocation functions (and many
other functions) in a typical libc were non-reentrant back then.  So
the chosen design was one that reused existing data structures as much
as possible.