On Thursday, 6 July 2023 at 13:48:52 GMT+8, suzuki toshiya
<mpsuz...@hiroshima-u.ac.jp> wrote:
> Are there any stable distributions of the
> prebuilt Skia binary, especially for Linux?
> The skia-python package has its own Skia
> binary (plus libbz2, libfreetype, libfontconfig,
> libpng, and libuuid).
Toshiya Kun,
Not any I know of. You are right, skia-python pip install comes with its own
skia binary, plus a few dependent library's. I also cloned skia-python and had
a quick look (already filed my first pull fixing a small mis-written doc, and a
missing feature issue - the guy says "pull welcomed", so I possibly will try to
build skia-python from source at some point). It bundles skia m87 from 2021,
and libfreetype 2.8 . Current skia is around m100 I think, as I remember
reading about "COLRv1 in m98" :-).
> In addition, even if there is an individual
> Skia package in some Linux distributions,
> maybe the Chromium browser would not use it
> - Chromium binary may merge the Skia into
> its binary, and there is no separate library.
I just checked chromium - it is a 200MB+ binary, which presumably includes the
~25MB skia in skia-python.
I think if anybody would try to modularize skia as a shared library it would be
the chromium people. So it hasn't been done yet.
> The skin-python can wrap up such issues, but
> I wonder whether the API of the prebuilt Skia
> binary in the PIP package is stable. And even
> if it is stable, I'm still wondering whether
> it is a good idea to link the binary content
> of the PIP package from the external (non-PIP)
> binaries. Are there any applications providing
> the Skia library as an individual component?
I think the first part of your question is yet. The bundled skia in skia-python
has been stuck at m87 for a couple of years, and there are a few open issues
filed at skia-python about updating it. As for the other two questions, I think
the last one is no, there is no effort (visible) of any party providing skia as
an individual component. As for the 2nd question - I think if the skia-python
people are clued-up, they would hid all the skia symbols with linker tricks,
and only expose the pybind11 python hooks - it is a performance itself to not
show too many public symbols more than necessary - so it may not even be usable
by non-PIP parties.
(I am thinking probably the opposite of what you are suggesting, a non-python
application re-using the prebuilt skia-python bundled skia, instead of what you
are aiming at, that skia-python using an external skia, which is also shared
with some non-python application) anyway, it looks like at the moment skia is
alwaya bundled in something else.
Regards,Hin-Tak
P.S. zoom call on 20 minutes!!!! How exciting!
