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

[Alan Third <alan@idiocy.org>]

On Tue, Dec 12, 2023 at 04:47:13PM +0200, Eli Zaretskii wrote:
> > From: Manuel Giraud <manuel@ledu-giraud.fr>
> > Cc: Alan Third <alan@idiocy.org>,  67794@debbugs.gnu.org
> > Date: Tue, 12 Dec 2023 15:07:13 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > Basically, SVG images specify their own background color, and the
> > > Emacs display cannot override that, since the image is generated by
> > > librsvg.  So to change the background color, we wrap the SVG in
> > > another SVG, see svg_load_image.  This way, the SVG spec submitted to
> > > librsvg specifies different colors according to what Emacs wants.  And
> > > we only do that for colors that come from 'face' properties.
> > 
> > This means that when you do a 'C-s foobar' and that the SVG is correctly
> > displayed with the isearch face (foreground and background), such an
> > embedded SVG was created on the fly?  If so, I think we should do the
> > same for mouse-face too because this SVG generation is very fast!
> 
> Not sure "fast" is fast enough, since unlike face properties,
> mouse-highlight is highly dynamic, and creating a new image each time
> (as I think this would mean) is something we want.  Let's wait for
> Alan to chime in with his insights.
> 
<snip>
> > As it was working with face such as isearch, my new strategy was to
> > find out how it worked here but now I don't know where/how to break
> > to the correct place.
> 
> show_mouse_face calls draw_row_with_mouse_face, which calls
> draw_glyphs, which builds a "glyph string" and then calls the frame's
> draw_glyph_string method, which on X is x_draw_glyph_string.  The
> latter eventually calls x_draw_image_glyph_string.  HTH.

Hmm, yes, that makes it harder. Images are loaded, and in the case of
SVGs rasterised, earlier in the process. We would presumably need to
create a whole new image and substitute it at the point where we draw
to the screen.

A quick look at nsterm.m's image code makes me think it should be
relatively straight forward to extract the image spec from
s->img->spec and generate a new image with the mouse face, however
this will happen for every image type, even very large images that
don't use face colours, and it will have to be implemented separately
in each term.

It could also result in some undesirable effects if the image file was
changed between redisplay calculating the original image size and the
substitute being created.
-- 
Alan Third