Canvaskit based Font rendering for SkPictures

[soh...@chromium.org]

Hi !

We are trying to playback SkPictures via Canvaskit in a JS environment, with API's like CanvasKit.MakePicture and canvas.drawPicture.

Most of the pages text rendering is comparable.
But for google search based pages, the font seems to default. Here is an example.

We are building our own Canvaskit release version via `compile.sh` from source, with no extra flags.

The text rendering works fine, when we playback via Skia Viewer natively.

Are there some font flags to toggle while building CK, to get the desired output ?

Or during SkPicture serialization, we have to explicitly set up SkSerialProcs to resolve this ?

Or something else ?

Any pointers.

Br,

Sohan

[bungeman]

It looks like the font data wasn't included. By default system fonts don't have their data included. If you do always want the data included you can do what Chromium's out of process printing does in SerializeOopTypeface / DeserializeOopTypeface [0] (and these are set on the SkSerialProcs/SkDeserialProcs). Of course, if you don't need the id based deduplication and your serial proc only uses `typeface->serialize` you can probably get away without implementing a deserial proc (the default one should work). Note that even if you do embed the data, CanvasKit only has access to the FreeType font deserializer. If the skp was recorded with DirectWrite or CoreText backed SkTypefaces it is possible that the glyphs may end up slightly different when measured and rendered with FreeType.

[0] https://source.chromium.org/chromium/chromium/src/+/main:printing/common/metafile_utils.cc;l=277;drc=566369da19275cc306eeb51a3d3451885299dabb

[Sohan Jyoti Ghosh]

Thanks ! Serializing typefaces explicitly via SkSerialProcs sounds good. 

Just to check, what would be the impact of skp sizes if we serialize the font data ? Will it cause extra memory churn ?

When we do regular Skp serialization (without custom procs), isnt the typeface's default serialized ? I think we were earlier seeing skp worth MB's for wikipedia.org kind of sites.

Br,

Sohan

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/7dc961cc-1715-48e1-818b-f715a1f3ac6an%40googlegroups.com.

[bungeman]

Any non-system font (like web fonts) will have its data serialized by default. These are the typefaces you're already seeing in the skps. Note that with really new Chromium Linux you may see all fonts data serialized due to a quirk of how they are loaded on Linux. On Windows and Mac any system fonts won't be data serialized by default though. And yes, embedding all the fonts can be a lot of memory. On Mac any use of emoji is likely to drag in Apple Color Emoji which is currently ~200MB. There are things that one could do to bring down the overall size like font subsetting, but in general if the data is needed it is needed.

[Sohan Jyoti Ghosh]

Thanks !

The above skp is captured via Chromium on Linux (m111) (similar to print path),

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/web_local_frame_impl.cc;l=556

I wonder if this path also has the quirks for serializing all font data.

https://source.chromium.org/chromium/chromium/src/+/main:components/paint_preview/common/serial_utils.cc;drc=566369da19275cc306eeb51a3d3451885299dabb;bpv=1;bpt=1;l=58

Br,

Sohan

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/a611622f-52cf-468b-a878-233e5e81150dn%40googlegroups.com.