It looks like the premake5 "v5.0.0-beta3" tag isn't compatible with
Sequoia 15.4.1. Bump our tag to v5.0.0-beta7 and update the deprecated
features we had been using.
Also fix the script to rebuild if the premake5 binary doesn't exist.
Before it only checked if the parent "premake-core" directory existed,
so if a build had failed previously, build_rive.sh would fail forever
without ever attempting to build premake5 again.
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Co-authored-by: Jonathon Copeland <jcopela4@gmail.com>
# Description
made decode Image implantation in `RenderContextHelperImpl` now defined in `RenderContext`
# Details
We were copy pasting the code for decoding into several places. Moving it to `RenderContext` allows us to have it in one spot and just be used by default.
Diffs=
e7b0480e4e refactor(renderer): pulled out decodeImage from context helper and made it platform decode (#9448)
Co-authored-by: Jonathon Copeland <jcopela4@gmail.com>
The renderer intentionally chose unmultiplied alpha for gradients, in order to not lose color information with transparent stops. But for this very same reason, we need *premultiplied* alpha for image textures. Otherwise, the (transparent) background color can bleed into edges. Switch image textures to premultiplied, while keeping gradients unmultiplied.
Diffs=
a70f0f84dd Switch image textures to premultiplied alpha (#9377)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Co-authored-by: blakdragan7 <jcopela4@Gmail.com>
Anybody who builds Rive knows this error:
cp: /Users/chris/code/rive/packages/runtime/renderer/dependencies/8E14B9975/libpng-libpng16/pnglibconf.h: Permission denied
This comes up because we need to generate pnglibconf.h, but Lua didn't like us trying to copy over a file that already existed. Make this cleaner by generating pnglibconf.h in %{cfg.targetdir}/include/libpng instead, and only do so if the file doesn't already exist.
Diffs=
60a2eec998 Fix the notorious pnglibconf.h error for v2 (#8905)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
This pull request adds support for both visionOS and tvOS to the Apple (colloquially referred to as iOS) runtime.
It should _not_ be a breaking change, since the only major API change is an internal one (see `RenderContext` below). I believe we should be able to make this a minor release. Developers who have subclassed `RiveView` or `RiveRendererView` should not see any changes, unless they were explicitly expecting this view to be `MTKView`, which is fully unavailable on visionOS (hence our recreation - see `RiveMTKView` below.
## Premake Scripts
The premake scripts were updated to add a few new variants for iOS:
- xros (visionOS devices; named after the internal sdk)
- xrsimulator (visionOS simulator; named after the internal sdk)
- appletvos (tvOS devices; named after the internal sdk)
- appletvsimulator (tvOS simulators; named after the internal sdk)
The majority of the work here is copy/pasting existing code, and just adding additional filters when these new options are used, primarily used to target the new SDKs / minimums for those SDKs.
## Shaders
Shaders are pre-compiled for visionOS and tvOS separately, and the correct shaders are then used later-on at compile time.
## Build scripts
Build scripts were updated to support building the new libraries, targeting the new devices, using the new options above. Additionally, they have to point to new output files.
The `build_framework` script has been updated to build the new libraries to add to the final output `xcframework`.
## Project
Example targets for both visionOS and tvOS, since these truly are the "native" apps, rather than just iPad-on-your-device. These use a new `streaming` riv by the creative team.
The tvOS example app adds additional support for remote control, since that behavior can be utilized in multiple ways during development; that is, we don't add any "default" behavior for remote controls. The visionOS app, on the other hand, works out-of-the-box with no additional changes.
## RenderContext
`RenderContext` is an internal type; it's forward-declared, so it's unusable outside of the scope of internal development. There have been some "breaking" changes here - the API has been updated to, instead of passing in `MTKView` around, using `id<RiveMetalDrawableView>`. This had to be changed, regardless, since visionOS does not have `MTKView`. The choice to use a protocol was because it forces a little more explicit initialization across platforms, rather than having a parent class that acts as an abstract class, but isn't abstract because it still needs some default values, but those values are different based on device and API availability, etc. We could've passed around `RiveMTKView` as the type, but with a protocol, there's a possibility of being able to use a type that isn't exactly a view, but might want to still act against the drawing process. Personal choice, really.
## RiveRendererView
`RiveRendererView` is now a subclass of `RiveMTKView`. `RiveMTKView`'s superclass depends on the device:
- On visionOS, this is a `UIView` with an underlying `CAMetalLayer`
- On all other platforms, `MTKView`
This new class conforms to `RiveMetalDrawableView`, which allows it to be passed to `RenderContext` types.
### RiveMTKView (visionOS)
`RiveMTKView` on visionOS is a subclass of `UIView` that is backed by a `CAMetalLayer`, providing the necessary properties of `RiveMetalDrawableView` (compile-time safety here, baby). This is quite a simple recreation of the default `MTKView`, since that type is not available on visionOS (thanks, Apple).
## Other things
Additional compile-time checks for platform OS have been added to make sure each new platform compiles with the correct APIs that can be shared, or otherwise newly implemented.
Diffs=
6f70a0e803 Add visionOS and tvOS support to Apple runtime (#8107)
Co-authored-by: David Skuza <david@rive.app>
Some platforms have native support for jpeg and png but sill need webp support.
Diffs=
5df5be1940 Add "no_rive_jpeg" and "no_rive_png" build options (#8702)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
This gives better support for smaller screens and side-by-side windows.
Also standardize the formatting check on GitHub on version 17.
Diffs=
e52e9fff29 Drop the ColumnLimit to 80 for clang-format (#8320)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
We've been needing this for a while for the game engines but we also need it to support decoding webp images for use in the editor with the Rive Renderer.
I haven't instrumented the build properly to use SIMD extensions, but I left some notes for how to do so. This PR unblocks the use of WebP, let's do some perf improvements in a follow up that perhaps the runtime team can own?
Diffs=
160d9eefb Add webp decoder. (#7883)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
Co-authored-by: rivessamr <suki@rive.app>
Support for SIMD instructions for unpremult
First checkin, using rive::int16x4 instructions : 1 pixel at a time
Further checkin, using rive::int16x4 instructions : 2 pixels at a time
Last checkin, avoid computation when opaque pixels (assume there will be enough opaque pixels to warrant this)
Thanks to Chris for the SIMD instructions usage in rive
More checkins: move the decode and unpremult to the rive decoder - this requires modifications to build files. The benefits are we are now running tests on this path. However, there are some issues with decoding two images for tests:
"../../test/assets/bad.jpg" ... Apple Preview app cannot open this image, however, the current test says that it should be not null
And
"../../test/assets/bad.png", Apple Preview app can load this images, however, the current test says that it should be null
Diffs=
e992059d6 iOS images unpremult SIMD support (#7875)
Co-authored-by: rivessamr <suki@rive.app>
Our png and jpeg decode methods suffer from overflow bugs caused when multiplying 32 bit dimensions that overflow 32 bits of storage. We fix this in two ways:
- bump factors to size_t when multiplying to ensure large valid files can be decoded
- check for overflow when passing row pointers for decoding or copying to ensure we don't access out of bounds memory
Also includes some cleanup using unique ptr in png decoding.
Also includes two tests with a bad png and a half-bad jpeg (half-bad as it can actually decode but provides incorrect/manipulated dimensions to attempt to cause overflow).
Issue reported here: https://github.com/rive-app/rive-cpp/issues/373
Diffs=
93fb6eb83 Fix jpeg and png decode overflows and error handling. (#7535)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
Addresses the Unity issues raised by Adam here: https://2dimensions.slack.com/archives/CLLCU09T6/p1718727712078119
libjpeg has a flag `NEED_SHORT_EXTERNAL_NAMES`, which renames functions to shorter names, however, I didn't use this approach because its possible we could get naming collisions if someone brings another 3rd party lib which also has this flag enabled.
Diffs=
a4439ee42 Renames for Yoga and libjpeg (#7446)
Co-authored-by: Philip Chung <philterdesign@gmail.com>
Original libjpeg (turbo was forked from an older version of this). Note C api is still the same.
Diffs=
45b998e68 Simple libjpeg (#7277)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
The bug @HayesGordon ran into with Unity was because we were trying to decode grayscale images to a single-channel image and then expanding those to 4 channels as the Rive Renderer expects RGBA. That was padding missing channel data with 255, which is why we were getting Cyan (R would be read, GBA were filled with 255).
Instead, we make the Bitmap library only work with RGB and RGBA and we let libpng do the expansion for us.
Glorious:
<img width="417" alt="CleanShot 2024-03-08 at 21 28 21@2x" src="https://github.com/rive-app/rive/assets/454182/326e537b-15ad-4914-acb7-a85ddc42c88c">
Diffs=
09feaccb0 Always decode 3 or 4 channel PNG images. (#6818)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
* Don't use an external premake extension for emscripten; just set up the environment ourselves to build with emscripten.
* Delete the spots that turned on the '-pthread' flag for emscripten.
* Get the WebGL and WebGPU builds compiling again and add a github workflow for them.
* Delete the bubbles example. It didn't compile on android or wasm and caused confusion. It's in the git history if we want it back.
Diffs=
ac0d97c12 Clean up emscripten build (#6531)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Some systems we want to integrate with expect these features.
Diffs=
d65b239c5 Add options to build with rtti and exceptions (#6121)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Rather than implementing a specific handler for this method, we add PaintType::image to PLS and implement drawImage() as drawPath() with a rectangle path and an image paint.
Diffs=
adeebb26a Implement drawImage() in PLS (#5780)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
This allows us to share bitmap bytes with code that doesn't have a depency on rive_decoders.
Diffs=
58cc49580 Add a Bitmap::detachBytes method (#5763)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
Add a packages/runtime/decoders project that can be reused by more projects than just the tess renderer.
Diffs=
b69ae1312 Lift tess decoders into a static lib (#5709)
Co-authored-by: Chris Dalton <99840794+csmartdalton@users.noreply.github.com>
