[MPEG-OTSPEC] the actual skia based ft2-demo ot-svg renderer hook code diff (Re: Success - Re: Skia-based ot-svg renderer hook to freetype)

[suzuki toshiya]

Dear Hin-Tak,

As one of the contributors of the FreeType and a person
who had once struggled with Skia, I'm very happy to hear
your progress report about the Skia-based backend of OT-SVG
for FreeType.

But I'm slightly questionable whether the subscribers of
MPEG-OTSPEC are enjoying samely.


Maybe some people in MPEG-OTSPEC have an interest in
"How many open implementations for OT-SVG are working?",
"What kind of new features in OT-SVG are expected?" or
"When the support of OT-SVG would be enabled by default,
or would it be easily configurable?". For such people,
your posting would be very useful. But the people interested
in the detailed comparison between the rsvg-backend and skia-
backend might not be the majority of the subscribers of
MPEG-OTSPEC.


I apologize for saying such an inflexible thing, but,
please reconsider the cross-posting (between the FreeType
developers list and the MPEG-OTSPEC list) for highly-
professional and deep implementation-dependent discussion
specific to FreeType.

Regards,
mpsuzuki

On 2023/07/13 4:43, Hin-Tak Leung wrote:
> 
> Here it is, the actuall code diff for adding skia as a ot-svg renderer hook to freetype, as an alternative to rsvg/cairo. There is a new file "README.skia". I fixed the color change and the intermittent crash, so as far as I know the only thing is that it is occasionally 1-pixel off compared to rsvg/cairo.
> 
> This can be somewhat corrected by changing these two lines:
> 
>      x = bounds.left();      -> floor(bounds.left());
>      y = bounds.top();      -> floor(boulds.left());
> 
> I am not convinced that skia is entirey wrong, actually; the equivalent rsvg location has some comments on doubts about rounding.
> 
> I thought of switching the hooks dynamically (between 3, rsvg_hook, skia_hook, and a new null_hook), but running init of one hook , switch in the middle and run the free of another hook is dangerous. So this is still done as a build-time change. Otherwise it would be great to switch dynamically to investigate the 1-pixel-difference problem.
> 
> For now, if somebody else wants to give this a try, especially a mac user or a windows user, and/or somebody want to build skia (I am lazy and just downloaded a not-too-old pre-built binaries), I like to hear about 1st-hand experience on that too.
> 
> The rest, please have a thought how to  switch the hook dynamically, without crashing....
> 
> will probably post this up at
> https://github.com/HinTak/harfbuzz-python-demos/ under a new directory "skia-adventure" and write there. Thanks for reading this far :-).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wednesday, 12 July 2023 at 07:28:15 BST, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:
> 
> 
> 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.