simple things first.
after some debugging on audio "ducking"
it looks like we only start to kill audio after we initialize the audio engine. this first "fix" simply prevents us from initializing the audio engine if its not already been initialized. when going into the background/foreground.
other than this, we initialize the audio engine when you first play an audio clip in `void AudioEvent::play()`
this still leaves an issue lying around where after we have initialized the audio engine we will now "forever" duck audio when we go into the background/foreground. but at least you should be able to avoid this entirely if you never load a file with audio.
Diffs=
d4b3118e1 only start/stop the audio engine if its been initialized (#7335)
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
…nDidResignActiveNotification
good spot on the bad notification, will push another build with this when in
Diffs=
14ea38786 name:NSApplicationDidFinishLaunchingNotification -> name:NSApplicatio… (#7102)
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
we seem to use `#if __has_include(<UIKit/UIKit.h>)` & `#if TARGET_OS_IPHONE` to determine if we are buidling for ios or not.
i'm not sure if it really matters which we use here, but i guess we should just use one of them, i kinda like the look of TARGET_OS_IPHONE more.
Diffs=
f20d5944a patch backgrounding to use macos notifications when appropriate (#7101)
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
- Fixes a crash when a sound is still playing and Artboard is de-allocated. Easy to cause with long sounds as sound resources would get nuked and the engine would keep trying to decode from a dead buffer.
- Stops audio when going in background, resumes when coming to foreground.
The way I did the backgrounding is on the RiveRendererView as I couldn't find a better general spot to do this but maybe @mjtalbot has an idea.
This does not stop long sounds (like songs) when exiting a view, we can address that separately...
Diffs=
4a9947630 Stop audio in iOS when backgrounded. (#7055)
Co-authored-by: Luigi Rosso <luigi-rosso@users.noreply.github.com>
few bits to sort out
- [x] make our mix of simulator/emulator consistent, settling on emulator
- [x] passing the factory in works great for just in time asset decoding, but its not amazing when you want to decode ahead of time.
- [x] couple of places left to pass this function signature through. (Question) is there a neater way to get this done, feels a bit like we are going back to parameter explosion a bit?
- [x] should do a few examples, i think the complexity grows quite a bit in this one as you add caching, or callbacks
- [x] should get the cached images/fonts to draw on init as well, either warming up cache, or jitting
- [x] examples loading assets from the bundle (also there seem to be actual asset things too? should we use those?!)
- [x] add test
- [x] re-add "preview" project & rev the preview project once this has been deployed. (do this after new ios deploy)
- [x] fix up race condition (see comment)
https://github.com/rive-app/rive/assets/1216025/2c14330f-e8a4-481b-bc27-4807cabe3b82
(simple example, both swift ui and standard)
Diffs=
fabb7f97f Ios out of band (#6232)
Co-authored-by: Gordon Hayes <pggordonhayes@gmail.com>
Co-authored-by: Maxwell Talbot <talbot.maxwell@gmail.com>
draft because i need to get a todo list together.
Adds macos as a target for our ios runtime! Also adds a macos target for our example (which is a different app completely, very minimalistic right now).
<img width="331" alt="CleanShot 2023-05-17 at 20 32 45@2x" src="https://github.com/rive-app/rive/assets/1216025/7a6cadce-9763-41a3-b1a0-6d067dfc3eca">
macos, macos rosetta, macos (designed for ipad), and ios all co existing in peace, from the same runtime project
todo:
- [x] update build scripts to build supporting macos (gotta do this)
- [x] run formatter
- [x] test out builds in forked version of ios? (gotta do this)
- [ ] one more stab at catalyst? (i think we can try that later...)
- [ ] do we need a more comprehensive example setup for macos (I think we can do this later & try to pull zach's examples in)
- [ ] I think we should restructure the ios project, but i think we can do that after this as well (i just think the folder structure/project structure can do with some work, now that we add macos (and should make room for tvos as well)
- [x] probably got tests to fix
- [ ] there's probably a bunch of looking at errors in the debugger and figuring those out, but i would hope that we can deploy with some warnings here too.
catalyst problem:
we get this error:
and the problem is basically that we can target a specific library for macos, but we need one for macos and one for macos catalyst. they share the same architecture, so i dont think we can lipo them into one file...
we could change the compiled binaries before creating the frameworks I guess though? .. maybe something to try..
`/Users/maxwelltalbot/development/rive/rive/packages/runtime_ios/dependencies/debug/librive_skia_renderer_macos.a(cg_factory.o), building for Mac Catalyst, but linking in object file built for macOS, file '/Users/maxwelltalbot/development/rive/rive/packages/runtime_ios/dependencies/debug/librive_skia_renderer_macos.a' for architecture arm64` basically
Diffs=
a9f8a1c5d Macos take2 (#5258)
Set of ios changes:
- Fixes a couple of memory leaks
- Implements ref counting for our graphics context, so we can ditch it if noone's using it
- few leftover notes about things i've not quite "solved" we still keep a hold of too much url data, but i think i want to get this change in. its been too long
Diffs=
1ddbb679a Ios memory shared context (#5169)
Also update the auto formatter to run on *.m and *.mm files, and effectively ban breaking on return types entirely, as I think this is ugly.
Diffs=
c7d125c7d Update ObjC formatting to look more similar to the C++
Reorganized the project to put it inline with the cleaner organization of the mac runtime
Diffs=
3468941d0 Reorganized the project to put it inline with the cleaner organization of the mac runtime
