Summary:
changelog: [internal]
Add more clang tidy rules to prevent common class of bugs.
Reviewed By: javache
Differential Revision: D39245194
fbshipit-source-id: 5521c5c4653d7005b96ebba494e810ba5075afbc
Summary:
We currently wrap colors in an object to make it look similar to a `PlatformColor` object, but since this is a hot codepath, let's just optimize it to a simple array of strings. The next step is to apply a layer of caching here, but this should be a simple improvement.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D31057046
fbshipit-source-id: f68e17167ddd5bba3b545d039600c7c9b40808f5
Summary:
Adds support for Animated.Color with native driver for iOS. Reads the native config for the rbga channel AnimatedNodes, and on update(), converts the values into a SharedColor.
Followup changes will include support for platform colors.
Ran update_pods: https://www.internalfb.com/intern/wiki/React_Native/Preparing_to_Ship/Open_Source_Pods/
Changelog:
[iOS][Added] - Support running animations with AnimatedColor with native driver
Reviewed By: sammy-SC
Differential Revision: D33860583
fbshipit-source-id: 990ad0f754a21e3939f2cb233bcfa793ef12eb14
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
This pull request aims to remove iOS 11 availability check which is no longer needed.
The minimum iOS deployment target for React Native is iOS 11 but we still have iOS 11 version check like below.
```
if (available(iOS 11.0, *)) {
```
This is a continuation pull request of https://github.com/facebook/react-native/pull/32151
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Changed] - Remove iOS 11 availability check
Pull Request resolved: https://github.com/facebook/react-native/pull/32488
Reviewed By: yungsters
Differential Revision: D32006312
Pulled By: ryancat
fbshipit-source-id: 0ee6579e433a15d3d220a52d2ccd6931b0513971
Summary:
Changelog: [Internal]
when we try to write a `SharedColor` type prop in the renderer, the template function we match to is the following:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/ReactCommon/react/renderer/core/propsConversions.h?commit=28dacb972cda702d37dedd4612bc67c212d4d9eb&lines=108-132
this is because `SharedColor` is an alias of `better::optional<Color>`. ultimately, this causes a crash in L130 - the template deduction in L130 interprets the T as an `int`, rather than `SharedColor`, but our `rawValue` is pointing to `SharedColor`.
there was a number of options i considered, but didn't feel the most correct:
- wrapping `SharedColor` in another `better::optional` - this felt like a hack and didn't really provide any real benefits of the `optional` wrapper.
- writing a template specialization on SharedColor - this didn't seem future proof because we could introduce another type that could potentially wrap an integer, which doesn't seem impossible in the future - then we would get some conflict with our `SharedColor` conversion, which is custom to the behavior of colors.
- coercing the template during the function call - from an engineering perspective, this didn't seem like a great idea since it isn't clear to the engineer that this would be necessary and they would most likely only find out to do this after seeing a crash on their builds.
i ultimately decided to convert `SharedColor` to a simple class wrapper, similar to the implementation already used in Android. this alleviates all of the concerns with the other options above.
Reviewed By: sammy-SC
Differential Revision: D30149880
fbshipit-source-id: 7e8abafcd9fd7465b13ef227d140e859f8df6ecd
Summary:
Changelog: [Internal]
in this diff, we iterate through the list of color passed down in the props, and write the RGBA value of the first valid UIColor
Reviewed By: sammy-SC
Differential Revision: D30110297
fbshipit-source-id: c6730110129d0fe1f784fa89cd26b46d3dda7f28
Summary:
Changelog: [Internal]
in this diff, we add the logic to handle converting PlatformColor strings to their corresponding RGBA values, using `UIColor`'s API as the source of truth of these colors.
functionality not covered yet:
- customColor
- iOS Dynamic Colors
- Variant Colors
Reviewed By: sammy-SC
Differential Revision: D30103451
fbshipit-source-id: 7d7be0f08dc2fb95b606b8f5d73784766787a574
Summary:
`isColorMeaningful` is the only place in xplat code that currently uses `colorComponentsFromColor`, which assumes that a color is an RGBA value. When implementing `PlatformColor` for windows, where colors might be complex patterns or effects, I'd like to keep the details of `SharedColor` isolated within `SharedColor`. This change moves `isColorMeaningful` into `color.cpp`, where each platform can provide an implementation that takes into account its platform specific color capabilities.
See https://github.com/microsoft/react-native-windows/pull/7801 for an example of window's SharedColor which can be either an RGBA value, or a name of a native color/brush.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - Move isColorMeaningful to platform specific code
Pull Request resolved: https://github.com/facebook/react-native/pull/31557
Test Plan: This shouldn't change any of the code, its just moving the existing function - normal CI/automation should be plenty of validation.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D28557698
Pulled By: mdvacca
fbshipit-source-id: 2a94850fe9c5037598107e1307f4153cee6491fb
Summary:
Currently, there is a bug with the way that fabric translates float values for color components to hex/int value (which android uses). There are two main problems with the current setup. The first is that we are using 256 as our ratio instead of 255 which is the maximum value for any color component in hex. The second is that we cast the components to ints instead of rounding which truncates the values. We uncovered this with UIQR because our off-by-one color values were incorrectly off a little bit extra for fabric surfaces.
Changelog: [Internal] updates the float-to-int value conversion for color components to be fully accurate
Reviewed By: shergin
Differential Revision: D26161396
fbshipit-source-id: 884e27ffa01b116f9307c00298bb8d888f9f6dd7
Summary:
This fixes a recently introduced crash in `colorComponentsFromColor()` (iOS implementation) caused by dereferencing a null pointer.
The fix is just a copy of a code fragment from a previous implementation.
Reviewed By: fkgozali
Differential Revision: D23944812
fbshipit-source-id: 977135dd75c4375affddfd75183e4890618ae819
Summary:
Finally, this diff changes the internal implementation of SharedColor to be `optional<int>`.
Initially, when we started working on the new renderer, it seemed like a good idea to allocated CGColor objects ahead of time and store them with Props. Now, this idea does not look so good, especially because:
* Having `SharedColor` as a `shared_ptr` is a quite big perf overhead for copying this thing. And the size of the object is not small.
* Having `SharedColor` as a `shared_ptr` creates huge interconnectedness among pieces of the core and rendering. E.g. improper releasing a pointer in some component view can cause a crash somewhere in the core (because both places might use the same shared `blackColor`.
On Android, we already use simple `int` as a representation of a color, and this works great. And this diff implements something very similar to Android, but a bit differently: here we use `optional<int>` instead of custom class with a single `int` field and some magic value that represents "empty value".
This approach should fix T75836417 because now we don't have allocation and deallocation when we simply assign color values.
If this solution works fine on iOS, I will do unify all implementations among all platforms.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753507
fbshipit-source-id: 42fd6cee6bf7b39c92c88536da06ba9e8cf4d4db
Summary:
This diff creates the Android OSS build system for the module react/renderer/graphics
As part of this diff I also moved android specific files to the folder react/renderer/graphics/platform/cxx/react/renderer/graphics folder
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22880975
fbshipit-source-id: 6899c3bb5ebce3a93d8487f49f1c253925a518e7
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Samuel Susla
Pieter De Baets
Genki Kondo
Andres Suarez
Kevin Gozali
Ken Tominaga
Phillip Pan
David Vacca
CodemodService FBSourceClangFormatLinterBot
Andrew Coates
Sara Valderrama
Valentin Shergin