Commit Graph

7 Commits

Author SHA1 Message Date
Valentin Shergin 920bd2c199 Fabric: Fixed crash in colorComponentsFromColor()
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
2020-09-25 17:28:40 -07:00
Valentin Shergin e4877ed985 Fabric: Using optional<int> instead of CGColorRef on iOS
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
2020-09-17 11:12:28 -07:00
empyrical 0693d08e2f Fabric: Explicitly include algorithm in Rect.h (#29884)
Summary:
This pull request adds an include statement including the header `<algorithm>` to `react/renderer/graphics/Rect.h`.

It is needed for building with MSVC because of the use of the `std::max` function. It seems that this header is included as a side effect of some other header that's being used when building with Clang, and for some reason it is not included when being built with MSVC.

## Changelog

Changelog: [Internal][Added] - Fabric: Explicitly include algorithm in Rect.h

Pull Request resolved: https://github.com/facebook/react-native/pull/29884

Test Plan: Files that include this header now successfully compile on MSVC.

Reviewed By: sammy-SC

Differential Revision: D23591910

Pulled By: shergin

fbshipit-source-id: d8367bbdd94bc66c05d8fa308ed46c7aca24a68a
2020-09-09 13:04:35 -07:00
Eloy Durán 941bc0ec19 Upstream RN macOS Hermes integration bits (#29748)
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.

As to the actual changes, these include:

* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.

All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.

## Changelog

[General] [Added] - Upstream RN macOS Hermes integration bits

Pull Request resolved: https://github.com/facebook/react-native/pull/29748

Test Plan:
Building RNTester for iOS and Android still works as before.

To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:

<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">

Reviewed By: TheSavior

Differential Revision: D23304618

Pulled By: fkgozali

fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
2020-08-27 01:18:33 -07:00
David Vacca b97619e0aa Make graphics module to compile in OSS
Summary:
This diff creates the Android.mk file for the fabric graphics module
This is necessary to enable fabric in RN OSS
changelog: [internal] internal

Reviewed By: fkgozali

Differential Revision: D22908219

fbshipit-source-id: 70ef1d06053b0ca07a71c0a2d36e4edd617b2a25
2020-08-06 00:09:12 -07:00
David Vacca 7c5be8015d Create Android OSS build system for react/renderer/graphics module
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
2020-08-06 00:09:11 -07:00
David Vacca 3093010ea5 move fabric to ReactCommon/react/renderer
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
2020-07-31 13:34:29 -07:00