| commit | 448cda297d1c21e3fc0a9ce63a8db1e4eca04af7 | [log] [tgz] |
|---|---|---|
| author | mjtalbot <hello@rive.app> | Wed May 08 15:09:23 2024 +0000 |
| committer | mjtalbot <hello@rive.app> | Wed May 08 15:09:23 2024 +0000 |
| tree | d233eedf489381adea1ee870026e5e87cbd05ce0 | |
| parent | 1fadc01a78f67f0599e98d91d36b1472b8b7f2c1 [diff] |
Wasm fallback and min safari version ### This PR - fixes WASM not loading on older Apple devices/browsers - adds a fallback mechanism #### Fix for older devices The addition of `MIN_SAFARI_VERSION` is the only flag that resolved the issue on the affected devices (see discussion: https://2dimensions.slack.com/archives/CLLCU09T6/p1714494911457529) #### Fallback This PR is meant to showcase a way to introduce a fallback mechanism quickly. Can it be merged? Yes. But we need to consider the impact and alternatives (see below). _Also note that this PR makes an assumption about the best way to handle our single packages, which needs to be discussed before merging (see below)._ #### Problem with this fallback We'll increase the NPM package size by having two WASM files: `rive.wasm` and `rive_fallback.wasm`. To alleviate any concern, this can be resolved with proper documentation. The packages that load the WASM remotely do so through `unpkg` or `jsdelvr` (or overridden manually). It would not have an impact on the actual end client (to my knowledge), but maybe the perception of the "increased" NPM package size is something we want to avoid. #### Benefit of this approach Quick, with minimal change. We continue to use `unpkg` and `jsdelvr` to host. #### TODO Adaptive Loading: Implement more sophisticated loading strategies, such as loading different WASM modules based on the user's browser capabilities or preferences. This draft PR only loads the fallback if the current one failed. This does not need to be part of this PR and can be a future enhancement. ### Single vs Non-Single versions **This fallback mechanism will only work for the non-single packages where we load the WASM bundle separately**. Not the **-single versions, where WASM is bundled with the JS. In my testing during the call to `loadRuntime` the callback for `locateFile` will not be called if Emscripten is built with `-sSINGLE_FILE=1`. At the time of making the draft PR I've not come up with a solution for this. It might not be possible. TODO: This needs to be investigated more. Or we should reach out to Emscripten. #### What this means If we can't create a fallback for these, then we should make a decision around our single libraries: - Should they prefer to support older architecture and we recommend that people use the non-single packages to benefit from the fallback mechanism. - Or the alternative and we still recommend using the non-single packages to benefit from a fallback. **There are other benefits to using the non-single:** - Streaming Compilation: Newer browsers can start compiling the WASM file as soon as it starts downloading, which could lead to faster execution start times. - Better Cache Control: JavaScript and WASM can be cached separately. If you update one, users may not need to re-download the other. With the single version, I can see how people may end up using it in a way where any update to their site might then be bundling everything again. ### Alternative One _Most of the above still apply._ Instead of adding `rive_fallback.wasm` to the current packages, we create another NPM package called `rive_fallback` or something. And all this package is responsible for is to distribute the fallback WASM files, for example, `rive_canvas_fallback.wasm` and `rive_webgl_fallback.wasm`. **Benefit** We do not increase the perceived NPM package size for our published packages. And we can continue to use `unpkg` and `jsdelivr` for hosting. ### Alternative Two _Most of the above still apply._ We build our own hosting with versioning, etc. Diffs= 4342a3f04 Wasm fallback and min safari version (#7214) Co-authored-by: Gordon <pggordonhayes@gmail.com> Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
Rive C++ is a runtime library for Rive, a real-time interactive design and animation tool.
The C++ runtime for Rive provides these runtime features:
We use premake5. The Rive dev team primarily works on MacOS. There is some work done by the community to also support Windows and Linux. PRs welcomed for specific platforms you wish to support! We encourage you to use premake as it's highly extensible and configurable for a variety of platforms.
In the rive-cpp directory, run build.sh to debug build and build.sh release for a release build.
If you've put the premake5 executable in the rive-cpp/build folder, you can run it with PATH=.:$PATH ./build.sh
Rive makes use of clang vector builtins, which are, as of 2022, still a work in progress. Please use clang and ensure you have the latest version.
cd skia/dependencies ./make_skia.sh // this will invoke get_skia.sh
To build viewer (plus you'll needed CMake installed)
./make_viewer_dependencies.sh
Uses the Catch2 testing framework.
cd dev ./test.sh
In the dev directory, run test.sh to compile and execute the tests.
(if you've installed premake5 in rive-cpp/build, you can run it with PATH=../../build:$PATH ./test.sh)
The tests live in rive/test. To add new tests, create a new xxx_test.cpp file here. The test harness will automatically pick up the new file.
There's a VSCode command provided to run tests from the Tasks: Run Task command palette.
rive-cpp uses clang-format, you can install it with brew on MacOS: brew install clang-format.
Note that if you‘re on MacOS you’ll want to install valgrind, which is somewhat complicated these days. This is the easiest solution (please PR a better one when it becomes available).
brew tap LouisBrunner/valgrind brew install --HEAD LouisBrunner/valgrind/valgrind
You can now run the all the tests through valgrind by running test.sh memory.
If you want to examine the generated assembly code per cpp file, install Disassembly Explorer in VSCode.
A disassemble task is provided to compile and preview the generated assembly. You can reach it via the Tasks: Run Task command palette or you can bind it to a shortcut by editing your VSCode keybindings.json:
[
{
"key": "cmd+d",
"command": "workbench.action.tasks.runTask",
"args": "disassemble"
}
]