* fix: Fix CI for "Build Android"
* update versions
* Update Gemfile.lock
* format swift
* fix: Fix swift lint
* Update .swiftlint.yml
* Use C++17 for lint
* fix: Fix C++ lints
Before, Frame Processors ran on a separate Thread.
After, Frame Processors run fully synchronous and always at the same FPS as the Camera.
Two new functions have been introduced:
* `runAtTargetFps(fps: number, func: () => void)`: Runs the given code as often as the given `fps`, effectively throttling it's calls.
* `runAsync(frame: Frame, func: () => void)`: Runs the given function on a separate Thread for Frame Processing. A strong reference to the Frame is held as long as the function takes to execute.
You can use `runAtTargetFps` to throttle calls to a specific API (e.g. if your Camera is running at 60 FPS, but you only want to run face detection at ~25 FPS, use `runAtTargetFps(25, ...)`.)
You can use `runAsync` to run a heavy algorithm asynchronous, so that the Camera is not blocked while your algorithm runs. This is useful if your main sync processor draws something, and your async processor is doing some image analysis on the side.
You can also combine both functions.
Examples:
```js
const frameProcessor = useFrameProcessor((frame) => {
'worklet'
console.log("I'm running at 60 FPS!")
}, [])
```
```js
const frameProcessor = useFrameProcessor((frame) => {
'worklet'
console.log("I'm running at 60 FPS!")
runAtTargetFps(10, () => {
'worklet'
console.log("I'm running at 10 FPS!")
})
}, [])
```
```js
const frameProcessor = useFrameProcessor((frame) => {
'worklet'
console.log("I'm running at 60 FPS!")
runAsync(frame, () => {
'worklet'
console.log("I'm running on another Thread, I can block for longer!")
})
}, [])
```
```js
const frameProcessor = useFrameProcessor((frame) => {
'worklet'
console.log("I'm running at 60 FPS!")
runAtTargetFps(10, () => {
'worklet'
runAsync(frame, () => {
'worklet'
console.log("I'm running on another Thread at 10 FPS, I can block for longer!")
})
})
}, [])
```
* feat: Allow returning of ImageProxy in a Frame Processor
* chore: Clean up
* fix: Missing space
* Update useFrameProcessor.ts
* Revert "Update useFrameProcessor.ts"
This reverts commit 9c645489cdfdf2079972669756a2cd20cc81e25e.
Technically `JHashMap` is duplicated now, but in separate namespaces. If I were to remove my `JHashMap` (and `JArrayList`) definitions, the user is forced to use fbjni v3.
* De-allocate `frame` HybridClass with JNI class loader if using Hermes
See 1b3a0c2612
* Don't wrap in `#if FOR_HERMES`, other `jsi::Runtime`s might also run GC on another Thread.
* Use `jni::local_ref` for `FrameHostObject`
* Update JImageProxyHostObject.cpp
* Only run with JNI `ClassLoader` if ctor Thread ID != dtor Thread ID
* Upgrade reanimated to 2.3.0-beta.1 to fix JNI crash
* Remove `this_thread::get_id()`
* Update Podfile.lock
* fix: Fix JNI <-> JSI conversion for Integers
* Create another plugin and call them both serially
* Use inline formatter for `__android_log_write`
* Update FrameProcessorRuntimeManager.cpp
* Log plugin class type
* Use `pluginGlobal->cthis()`
* Log class name
* fix dumb error
* C++: Dynamically get JNI `javaPart_` class & method
* clean up PR
* fix: Fix UI Thread race condition in `setFrameProcessor(...)`
* Revert "fix: Fix UI Thread race condition in `setFrameProcessor(...)`"
This reverts commit 9c524e123cff6843d7d11db602a5027d1bb06b4b.
* Use `setImmediate` to call `setFrameProcessor(...)`
* Fix frame processor order of applying
* Add `enableFrameProcessor` prop that defines if a FP is added
* rename constant
* Implement `enableFrameProcessor` prop for Android and make `frameProcessorFps` faster
* link to troubleshooting guide
* Update TROUBLESHOOTING.mdx
* Add logs for use-cases
* fix log
* set initial frame processor in `onLayout` instead of `componentDidMount`
* Upgrade CameraX to alpha6
* Upgrade CameraX extensions to alpha26
* `init` -> `getInstance`
* Use new Extensions API
* Update CameraView.kt
* use new ExtensionsManager API in `getAvailableCameraDevices()`
* fix cpplint errors
