Re: [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)

[Hin-Tak Leung]

(removing OTSPEC list off CC')

Toshiya Kun,

Most of us simply ignore e-mails we aren't interested in reading... so as long as the subject title reflect the content and people have a choice of NOT opening the e-mail, I see no problem of posting about matter of limited interests. Fonts itself is already a topic not interesting to most people. I certainly don't read every e-mail arriving immediately, some of them not for a few days, some perhaps after a month or two, some left unopened for a long time.

As for the actual subject matter. I think it is highly queationable that Google put more and earlier effort on suporting "not yet a spec" than "been a spec for 4 years". The primary failure is the idea that everything runs inside a web browser... A lot are, but not everything. Google folks can predict OT-SVG will be obsolete, BECAUSE Google chrome does not support it. :-). Maybe putting skia underneath FreeType and support ANG application will means that OT-SVG has a better future. That, I think is a matter of discussion on OTSPEC - the long term future of OT-SVG.

Anyway, I fully expect people to stop reading at some point, and they should :-).

Regards,
Hin-Tak


On Thursday, 13 July 2023 at 02:21:39 BST, suzuki toshiya <mpsuzuki@hiroshima-u.ac.jp> wrote:


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@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.