infra: use unbundled rapidjson

[bkmgit]

Am packaging thorvg for Fedora linux. It is preferred to use system libraries. As such it would be helpful to add an option to meson to allow use of the system rapidjson libraries instead of the one bundled with thorvg.

[bkmgit]

Would a merge request to add this functionality be considered?

[hermet]

@bkmgit yes, i think so.

[hermet]

@bkmgit Just in case, please let us know if you'd like to contribute that enhancement yourself. Thanks.

[bkmgit]

Yes, will contribute this functionality.

[bkmgit]

Start of packaging process https://bugzilla.redhat.com/show_bug.cgi?id=2354812

[hermet]

Yes, will contribute this functionality.

Cool, I expect ThorVG can detect RapidJSON installed on the system at build configuration time. If it's found, ThorVG can depend on it; otherwise, it will continue using the built-in RapidJSON.

[bkmgit]

There are some differences, and using the packaged RapidJSON fails to build:
https://download.copr.fedorainfracloud.org/results/fed500/thorvg/fedora-rawhide-x86_64/08832034-thorvg/builder-live.log.gz

There have not been any recent releases of RapidJSON, see Tencent/rapidjson#2284 and the last release 1.1.0 does not contain IterativeParseInit()

RapidJSON commit 2a1f586(https://github.com/Tencent/rapidjson/tree/2a1f586ba692ecbbf6d63c8ffbd4d837b1d4a9a4) was added on 26 July 2023 after a comparison with simdjson:
250e2d7 primary criteria being size.

The branches other than 0.11.x have additional changes on top of the bundled RapidJSON.

Would it be possible to add the option of using alternative json libraries? Some options include:

• Glaze
• simdjson
• cJSON
• json-build
• ojc
• nlohmann-json
• jsoncpp
• json-c
• jansson
• yyjson

Other than size, is speed important? Is it ok if the library is not header only? Is there a preference for C over C++?

Finally, the Fedora build includes the following patch:
Tencent/rapidjson#1261
related to CVE 2024-39684, see https://src.fedoraproject.org/rpms/rapidjson/blob/rawhide/f/rapidjson.spec - probably this code execution path is not exercised by lottie, but if it is, it maybe helpful to apply it to all branches.

[bkmgit]

json code is only used to read in lottie files and is referenced in https://github.com/thorvg/thorvg/blob/main/src/loaders/lottie/tvgLottieParserHandler.h#L78 and https://github.com/thorvg/thorvg/blob/main/src/loaders/lottie/tvgLottieParserHandler.cpp#L160 which read in json token by token.

yyjson is an actively maintained C code that can be incorporated directly or linked as a library.

nlohmann-json is an actively maintained C++ single header file.

yyjson is probably faster and if included, when compiled with optimization only used functions will be in the resulting binary. nlohmann-json maybe easier to use.

[bkmgit]

While not actively maintained jsmn is the smallest code ~500 lines of C and just parse json. Maybe easier to use this as the basis for a parser if that is all that is needed and speed is not a concern?

[hermet]

While not actively maintained jsmn is the smallest code ~500 lines of C and just parse json. Maybe easier to use this as the basis for a parser if that is all that is needed and speed is not a concern?

@bkmgit I think we need to carefully investigate for changing the json parser. Both speed and size are major criteria that need to be considered. We can make a decision based on a compromise between them, and if something surpasses rapidjson, we can consider replacing it.

[hermet]

History: #692

[bkmgit]

Ok. Will create a couple branches, one for each implementation and then compare.