freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: benchmarking and plans for upstreaming the 4-hook patch, and COLRv1


From: Hin-Tak Leung
Subject: Re: benchmarking and plans for upstreaming the 4-hook patch, and COLRv1 extension.
Date: Tue, 25 Jul 2023 19:29:00 +0000 (UTC)

The script to download and build skia with 80MB download and 300MB disk use is at
https://github.com/HinTak/skia-building-fun .
Takes about 40 minutes on dual core.

Most things about the 4 hooks and COLRv1 extension stays at
https://github.com/HinTak/harfbuzz-python-demos

But a COLRv1-related patch will land in the building fun repo at some point, to patch skia with a few extra routines etc to make getting at COLRv1 functionality easier...

On Monday, 24 July 2023 at 09:59:32 BST, Hin-Tak Leung <htl10@users.sourceforge.net> wrote:


Hi,

The most exciting thing I have done this weekend, is managed to have a procedure/patch-sets to build current skia with max download/clone of about 80MB and max disk usage of about 300MB. Skia takes about 40 minutes to build on dual-CPU (or about 70 minute on single CPU). Without compromising on any functionality.

Skia is facinating in both a bad and good way. The official build procedure does a 900MB clone, then fetch 1.6GB swiftshader (mac os x only), 1GB icu (available on Linux), 400MB angle2 (used only windows builds); 5.1GB of thirdparty stuff in total. Then it goes and fetch another 400 MB via emsdk and dump 1.1GB on the hard disk (only useful for building skia for web-assembly). So it eats up 900MB + 5.1GB + 1.1GB ~ 7.1GB before you even start to build any skia source code. !!!

If you do shallow clone, only care about linux, and use system libraries as appropriate, you can cut the 7.1GB disk usage down to about 270MB. And the network usage from 600MB + ~2.5GB + 400MB ~ 3.5GB to about 80MB download.

So I think we can already start talking about upstreaming the 4-hook diff, because it is now possible to build the whole thing entirely from source without ready-made binary bits from elsewhere, in about an hour. And going towards the COLRv1 extension.

Here is what I have in mind in 4 stages:

- there are two uncontroversial diffs: adds no_svg /color layer glyph toggle keys to ftgrid, and symbol hiding in rsvg-port.c . The svg hook routines are entirely used via "hook->svg_init", so they don't need to be named at all.

- At the moment I use something like this in the Makefile:

+ $(OBJ_DIR_2)/rsvg-port.$(SO): $(SRC_DIR)/rsvg-port.c $(SRC_DIR)/rsrvg-port.h
+ $(COMPILE) $T$(subst /,$(COMPILER_SEP),$@ $<)
+
+ $(OBJ_DIR_2)/rsvg-port-alt.$(SO): $(SRC_DIR)/rsvg-port.c $(SRC_DIR)/rsvg-port.h
+ $(COMPILE) -DUSE_ADOBE=1 $T$(subst /,$(COMPILER_SEP),$@ $<)

FTCOMMON_OBJ := $(OBJ_DIR_2)/ftcommon.$(SO) \
$(OBJ_DIR_2)/ftpngout.$(SO) \
- $(OBJ_DIR_2)/rsvg-port.$(SO)
+ $(OBJ_DIR_2)/rsvg-port.$(SO) \
+ $(OBJ_DIR_2)/rsvg-port-alt.$(SO)

To build the same source file twice, differently, to switch between "rsvg + cairo" and "adobe + cairo". This trick depends on the symbol hiding change. We need something better and more configurable than this?

The current assumption is that "svg-native-viewer/" is a sub-directory, and have a separate set of build instructions.

- Once we have figured out the "rsvg + cairo" and "adobe + cairo" combination, then, the pair "adobe + (older/any) skia" and " pure skia (m103+)" can be switched the same way. The current assumption is that skia m116 (currrent) is a sub-directory, and again have a separate set of build instruction, plus modifying the previous step to build "svg-native-viewer/" with dual cairo and skia backend.

- then we can think about adding the COLRv1 difff. Currently, I have "-s 1/2/3" to switch between the 4 hooks at start, and using the layer-glyh toggle key 'z' (which has no effect currently on anything other than ftview), I can toggle the over-writing of svg rendering with COLRv1 rendering, and also over-loaded the palette switching key 'C' (for switching color-blind friendly glyf outline annotation, actually) for COLRv1 palette switching. So I have already got a build that I can turn all these features off, and go back to stock behavior. (the last rpm added in https://github.com/FontVal-extras/binary-archive/)

$ ls -l /usr/lib64/librsvg-2.so.2.48.0
-rwxr-xr-x. 1 root root 4396424 Jul 1 01:00 /usr/lib64/librsvg-2.so.2.48.0

$ rpm -ql freetype-demos | grep -E '(bin|lib64)'| xargs ls -l
-rwxr-xr-x. 1 root root 36680 Jun 27 01:00 /usr/bin/ftbench
-rwxr-xr-x. 1 root root 15800 Jun 27 01:00 /usr/bin/ftchkwd
-rwxr-xr-x. 1 root root 679368 Jun 27 01:00 /usr/bin/ftdiff
-rwxr-xr-x. 1 root root 48696 Jun 27 01:00 /usr/bin/ftdump
-rwxr-xr-x. 1 root root 662920 Jun 27 01:00 /usr/bin/ftgamma
-rwxr-xr-x. 1 root root 787768 Jun 27 01:00 /usr/bin/ftgrid
-rwxr-xr-x. 1 root root 28152 Jun 27 01:00 /usr/bin/ftlint
-rwxr-xr-x. 1 root root 15904 Jun 27 01:00 /usr/bin/ftmemchk
-rwxr-xr-x. 1 root root 671080 Jun 27 01:00 /usr/bin/ftmulti
-rwxr-xr-x. 1 root root 15792 Jun 27 01:00 /usr/bin/ftpatchk
-rwxr-xr-x. 1 root root 750968 Jun 27 01:00 /usr/bin/ftstring
-rwxr-xr-x. 1 root root 15856 Jun 27 01:00 /usr/bin/fttimer
-rwxr-xr-x. 1 root root 24400 Jun 27 01:00 /usr/bin/ftvalid
-rwxr-xr-x. 1 root root 771352 Jun 27 01:00 /usr/bin/ftview
-rwxr-xr-x. 1 root root 6863136 Jun 27 01:00 /usr/lib64/libskia.so
-rwxr-xr-x. 1 root root 380352 Jun 27 01:00 /usr/lib64/libskottie.so
-rwxr-xr-x. 1 root root 23840 Jun 27 01:00 /usr/lib64/libskparagraph.so
-rwxr-xr-x. 1 root root 14984 Jun 27 01:00 /usr/lib64/libsksg.so
-rwxr-xr-x. 1 root root 58584 Jun 27 01:00 /usr/lib64/libskshaper.so
-rwxr-xr-x. 1 root root 15128 Jun 27 01:00 /usr/lib64/libsktext.so
-rwxr-xr-x. 1 root root 37056 Jun 27 01:00 /usr/lib64/libskunicode.so
-rwxr-xr-x. 1 root root 252840 Jun 27 01:00 /usr/lib64/libsvg.so

The main skia library is 6.9MB vs librsvg's 4.4MB . The 600k addition to the 6 binaries which has ftcommon dependency, is mostly because I have the adobe code as static. (I will consider changing it ...).

Now that I am building skia from source - and patching it lightly - some of the bad things I did in the COLRv1 extension, can be done differently. and cut the diff from 115k (about 3000 lines!) to closer to the 4-hook diff (34k, just over 1000 lines).
I think the COLRv1 diff (which includes the 4-hook code) can be cut down to about 1200 to 1300 lines, if I am allowed to modify skia and re-compile :-).

At the moment, I am modifying 5 lines of skia source code. That, strictly speaking, is a Skia bug, filed as
https://bugs.chromium.org/p/skia/issues/detail?id=14636 . I don't have to have that 5 lines changed - it just makes the build smaller. So I am essentially using unmodified latest Skia from source.

I have a suspicion that the skia code is faster than the rsvg code. Is there an option in ftbench to do that? Rendering ot-svg to bitmaps via different hooks and compare speed, I mean.

Hin-Tak

P.S. filed a pull and a few issues at adobe/svg-native-viewer too, but they are relatively minor and you can go and read them at
https://github.com/adobe/svg-native-viewer/pull/189
https://github.com/adobe/svg-native-viewer/issues/186, 187, 188
and also

https://github.com/adobe/svg-native-viewer/issues/185

reply via email to

[Prev in Thread] Current Thread [Next in Thread]