[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#35468: [PATCH] Refactor draw_glyph_string on X and w32
Date: Sun, 05 May 2019 19:00:09 +0300

> Date: Sun, 5 May 2019 09:10:38 +0900
> From: address@hidden
> Cc: "Eli Zaretskii" <address@hidden>,
>  address@hidden
> >> 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)?


reply via email to

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