bug#35468: [PATCH] Refactor draw_glyph_string on X and w32

[Eli Zaretskii]

> Date: Sun, 5 May 2019 09:10:38 +0900
> From: mituharu@math.s.chiba-u.ac.jp
> Cc: "Eli Zaretskii" <eliz@gnu.org>,
>  35468@debbugs.gnu.org
> 
> >> And what does glyph_image_uses_mask hide?  AFAIU, the current code
> >> simply looks at s->img->mask, and if so, why do we need an interface
> >> for that?
> >
> > I was thinking that since AFAIU the Cairo drawing doesn't set
> > s->img->mask it wouldn't make sense, from an interface POV, to check it
> > directly. I suppose it doesn't really matter in that case, and it would
> > be faster to just check s->img->mask even if the backend doesn't use it.
> 
> IMO, image support for cairo is still premature and needs some
> restructuring.  It does not support postprocessing (:conversion
> ALGORITHM), mask removal (:mask nil), or image-mask-p.  Bitmaps
> for some image format are not stored in the premultiplied alpha
> format that cairo expects.
> 
> All of them are supported in the Mac port and I set dummy
> s->img->mask there (not containing the actual mask bitmap data)
> if the image has an alpha channel.  Probably setting a bitfield
> for the existence of mask (alpha channel) when creating image
> data would work as an alternative way.

Would you like to propose the abstractions for this that are supposed
to be future-proof (if what Alex shows isn't already sufficiently so)?

TIA