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