[MPEG-OTSPEC] Success - Re: Skia-based ot-svg renderer hook to freetype
Hin-Tak Leung
htl10 at users.sourceforge.net
Wed Jul 12 08:28:15 CEST 2023
See attached screenshot. Left is skia-based ftview/ftgrid, right is my system-wide ftview/ftgrid 2.13.0 (based on rsvg/cairo). The default zoom level for ftgrid seems to have changed between 2.13.0 and 2.13.1 from 4 to 6?
There are 3 issues I see
- the first one is of course the color - seems to be a rgba vs bgra difference? i.e. the Alpha channel is the same, but red and blue swapped.
- 2nd one is not very noticeable on ftview but more on ftgrid - the glyph is shifted down by one pixel. Probably a rounding error somewhere.
- I have intermitent crashes from 'include/core/SkRefCnt.h:72: fatal error: "assert(this->getRefCnt() > 0)" ' . Prove I don't know Skia well enough yet. ( That's one week of learning Skia ...)
On the way also learns a few things - this is based on m110 . I see that even with main (close to m116), one of the headers I am using have changed location.
I tried updating skia-python 's bundled skia from m87 to m88 - just 1 milestone, or roughly 4 weeks, to get a feel of how easy/hard it is. The main reason is that m88 is the first where the SVGDOM class is declared non-experimental. So I expect the SVG related headers to move. But the actual diff is close to about 1000 lines, took me a whole day. (by comparison, the fontval diff is a little over 4000 lines, and took 3 years). The amount of changes in skia per milestone is just alarming. That explains why nobody wants to ship skia shared libraries, and why skia-python is stuck at m87 for 2 years. Skia is just contantly changing from milestone to milstone.
That said, I think somebody should update skia-python's bundled skia from m87 to m98 (COLRv1) and perhaps even m103 (OT-SVG). Google folks?
One milestone is about 1000 lines of code difference and a whole day, I reckon it will take somebody working full time for 2 months to update skia-python to current-ish. (116 - 87 = 29 working days..., by the time one gets to m116, m117/m118 would be out...). If google folks are not moving a finger, and somebody else wants to fund me to tackle this, please feel free to get in touch.
I'll tidy the diff up and send it to freetype-devel at some point. At the moment it is just replacing all contents of rsvg-port.{c,h}. with
-#ifdef HAVE_LIBRSVG
+#ifdef HAVE_SKIA
...
- SVG_RendererHooks rsvg_hooks = { NULL, NULL, NULL, NULL };
+ SVG_RendererHooks skia_hooks = { NULL, NULL, NULL, NULL };
...
(void)FT_Property_Set( handle->library,
- "ot-svg", "svg-hooks", &rsvg_hooks );
+ "ot-svg", "svg-hooks", &skia_hooks );
...
So potentionally I can add a toggle key to dynamically switch between rsvg/cairo to skia rendering by just swapping &rsvg_hooks with &skia_hooks on the fly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: skia-based Screenshot from 2023-07-12 06-02-51.png
Type: image/png
Size: 300256 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20230712/7d3a60f1/attachment-0001.png>
More information about the mpeg-otspec
mailing list