bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40845: SVG rendering issues


From: Alan Third
Subject: bug#40845: SVG rendering issues
Date: Sat, 22 Aug 2020 23:35:46 +0200 (CEST)

On Sat, Aug 22, 2020 at 10:17:53PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 22 Aug 2020 20:57:59 +0200 (CEST)
> > From: Alan Third <alan@idiocy.org>
> > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com
> > 
> > Basically, if you try Clement's original example, when you move the
> > mouse over the image the background colour doesn't change to match the
> > rest of the line.
> > 
> > I'm picking up the background colour from the face stored in "it" in
> > push_prefix_prop or handle_single_display_spec in xdisp.c. As far as I
> > can tell one or both of these are the only places we can define the
> > image with the face colours as this is where we actually load the
> > image. The problem is that I don't see any way to work out if the
> > current image should use the background colour from the mouse face.
> > 
> > I know that later on we can do (s->hl == DRAW_MOUSE_FACE), but I don't
> > think those structures are built yet?
> 
> I think you want to modify note_mouse_highlight so that it sets up the
> frame's mouse-highlight info for image glyphs, like it currently does
> for character glyphs.  It's possible this is all that needs to be
> done; if not, we should see how to change show_mouse_face and its
> subroutines to display images with mouse-highlight.
> 
> Let me know if you need more guidance.

Thanks for your help, and that certainly helped me understand a bit
more about how mouse highlighting works and I don't think setting the
background colour from a face is a practical way of doing this.

But I've just realised we don't need to do it. Masks provide this
functionality. If you want the background of your SVG to match the
background of the buffer, use a mask, which can be keyed off a
specific colour or whatever.

Unfortunately it won't work well for semi-transparent images, but I
think the only really practical solution for that is to introduce
proper transparency handling.

Therefore I think this patch is ready to go.
-- 
Alan Third





reply via email to

[Prev in Thread] Current Thread [Next in Thread]