Open kalenikaliaksandr opened 1 month ago
IMO replicating the extremely ad-hoc Gfx::Painter
machinery just to get ugly pixelated emojis with Skia would be a poor use of time. I would rather see us directly moving to SkTypeface
and friends, and then getting good-looking system emojis.
IMO replicating the extremely ad-hoc Gfx::Painter machinery just to get ugly pixelated emojis with Skia would be a poor use of time.
sure, although it would be cool to get Skia painter on par in terms of completeness, so we could make it a default.
hackish idea how to get Skia text rendering without big refactoring: make Gfx::Typeface always carry a raw binary, so we can construct SkTypeface right before rendering.
IMO replicating the extremely ad-hoc Gfx::Painter machinery just to get ugly pixelated emojis with Skia would be a poor use of time.
sure, although it would be cool to get Skia painter on par in terms of completeness, so we could make it a default.
I think it's good enough that we could make it the default right now :)
DisplayListPlayerSkia::draw_glyph_run()
should not ignoreDrawEmoji
s in a glyph run and blit them from a bitmap, like it already does forDrawGlyph
. You would probably want to look at how Gfx::Painter handles emojis and replicate its behavior using Skia APIs.Just to clarify, Skia has its own text rendering capabilities, and we would like to start using them in the future. Currently we are not using them, because there is not way to construct
SkTypeface
fromGfx::Typeface
because raw font binary is gone by the time we reach painting. Fixing that would require larger refactoring, but we can totally get there eventually.HTML that is currently not rendered currently with
--enable-skia-painting
: