Summary:
This is a long story. Awhile ago awesome Nick Lockwood (Hey Nick!) introduced a special optimization for ReactNative rendering layer called "inherited background color".
He described this idea in D2811031:
>>>
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just <Image/> and <Text/> components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except <Text/> nodes. It might still be useful for <Image/> nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
However. I think it is time to remove it. Why? There are several reasons:
* It drastically complicates rendering layer. DRASTICALLY. In many many unrelated places (try search for "backgroundColor"!);
* This mechanism is totally non-conceptual to RN and it prevents us to implement some new possible render optimization that we plan to do;
* This adopted only by two components now: Text and ART;
* This is not a significant performance drain anymore; from iOS 6 even UILabel has clear background color by default.
* I doubt that it even works now because `drawRect:` in Text component does not call super method.
So, this diff just turns this feature off for Text. If all performance metrics are neutral, I will delete this mechanism.
Peace.
Reviewed By: sahrens
Differential Revision: D6564199
fbshipit-source-id: 70524fdd955ca32bbf86d2d1ff5e73316b791219
Summary:
Fixes the Flow failure due to an undefined Ast type.
Before:
```
$ npm run flow -- check
> react-native@1000.0.0 flow /Users/hramos/git/react-native
> flow "check"
Error: local-cli/__tests__/fs-mock-test.js:27
27: beforeEach(() => {
^^^^^^^^^^ beforeEach. Could not resolve name
Error: local-cli/__tests__/fs-mock-test.js:53
53: expect(content).toEqual('beep');
^^^^^^ expect. Could not resolve name
Error: local-cli/__tests__/fs-mock-test.js:88
88: expect(content).toEqual('hello, world!');
^^^^^^ expect. Could not resolve name
Error: local-cli/__tests__/fs-mock-test.js:100
100: expect(content).toEqual('hello, world!');
^^^^^^ expect. Could not resolve name
Error: node_modules/metro/src/Bundler/util.js.flow:46
46: ): Ast {
^^^ Ast. Could not resolve name
Error: node_modules/metro/src/ModuleGraph/worker/collect-dependencies.js.flow:283
283: const xp = (module.exports = (ast: Ast) =>
^^^ Ast. Could not resolve name
Error: node_modules/metro/src/assetTransformer.js.flow:29
29: ): Promise<{ast: Ast}> {
^^^ Ast. Could not resolve name
```
After
```
$ npm run flow -- check
> react-native@1000.0.0 flow /Users/hramos/git/react-native
> flow "check"
Error: local-cli/__tests__/fs-mock-test.js:27
27: beforeEach(() => {
^^^^^^^^^^ beforeEach. Could not resolve name
Error: local-cli/__tests__/fs-mock-test.js:53
53: expect(content).toEqual('beep');
^^^^^^ expect. Could not resolve name
Error: local-cli/__tests__/fs-mock-test.js:88
88: expect(content).toEqual('hello, world!');
^^^^^^ expect. Could not resolve name
Error: local-cli/__tests__/fs-mock-test.js:100
100: expect(content).toEqual('hello, world!');
^^^^^^ expect. Could not resolve name
```
[ GENERAL ] [ BUGFIX] [ .flowconfig ] - Have Flow ignore Metro node_nodules
Closes https://github.com/facebook/react-native/pull/17187
Differential Revision: D6572303
Pulled By: hramos
fbshipit-source-id: aa256b9725970fcc2a6da6578c83e7c0875e3cfd
Summary: JSON.stringify will convert a function to null, but folly::dynamic in the native code can't represent a JS function. Props do sometimes have functions, but don't permit them everywhere.
Reviewed By: johnislarry
Differential Revision: D6541878
fbshipit-source-id: b2a9d3ba7899dfb98a6a2ada3aa91a26549fdd94
Summary: Following common ObjC pattern, we have to store delegates as weak pointers.
Reviewed By: mmmulani
Differential Revision: D6558886
fbshipit-source-id: 11a710a7e9e17d7c6a78ae46b53b043f44ccf8e5
Summary:
We are removing `reactBridgeDidFinishTransaction`.
Why?
* It is a performance drain. Supporting this requires dispatching main-thread block on every single transaction complete;
* It has "too broad" non-conceptual semantic which encouraged using this as a "band-aid solution" for poorly designed components;
* It is conceptually incompatible with new approaches that we are trying to implement to optimize the render layer;
* It was deprecated for very long time.
This diff removes `reactBridgeDidFinishTransaction` from RCTScrollView component. As I mentioned, because of the semantic of `reactBridgeDidFinishTransaction` is extremely broad, it's hard to capture what exact case it should handle. Based on comments and existing logic, it seems it tight to `contentSize` property and the size of RCTScrollContentView.
Reviewed By: rsnara
Differential Revision: D6538419
fbshipit-source-id: ccc6f5fea327471f10f1738d3da5214c0d362953
Summary:
Because it is not simply flushing, it (in the future) is more complex process. And the names should represent logical meaning of the process, not particular implementation details.
It also nice to have unified terminology across our reactive UI frameworks.
See the next diffs.
Reviewed By: rsnara
Differential Revision: D6436770
fbshipit-source-id: 0a0b686e8ace89e30f6787a37c0a7965c5af757b
Summary:
This change aims at replacing SYSTEM_ALERT_WINDOW/OVERLAY API being used for rendering dev support related views on Android (redbox, dev menu, green loading view) with API that does not require any special permission. The permission is still used for displaying perf monitor, although it is no longer requested at app startup but only when perf monitor gets enabled.
This change should not affect the way react native apps work in production environment as in release mode all dev support functionality is disabled.
There are two main reasons why requiring SYSTEM_ALERT/OVERLAY permission for displaying basic dev related windows is problematic:
1) On Android >=6 devices it is required that overlay permission is granted in device settings for apps being side loaded (not installed via play store which is usually the case for apps being developed). Although this setting is not available on some Android devices including Google's stock Android TV version. On such devices App cannot be granted rights to draw in system alert window which cases the app to crash (instead of showing a redbox or dev menu dialog)
2) Some Android device vendors have issues with implementation of `Settings.canDrawOverlays` that always return false (I've seen it on Xiaomi Redmi 4A with Android 6.1). This issue because of the following code in [ReactActivityDelegate.java#L90](1e8f3b1102/ReactAndroid/src/main/java/com/facebook/react/ReactActivityDelegate.java (L90)), results in the overlay permission settings screen popping up every time the app is launched even though the permission has been perviously granted which is extremely annoying. Since this change only require overlay permission for displaying perf monitor we no longer ask for it on startup but only when user switches perf monitor ON.
Test need to be performed on pre Android 6 and post Android 6 devices.
1. Run app with devserver off -> should result in redbox
2. Start packager with --reset-cache flag for the loading bar to be visible for some longer period of time. Then restart the app and see the loading bar show up
3. While the app is running, open dev menu, navigate to "dev settings", test "reload"
4. Modify JS app such that the app crashes, see it display redbox properly. Check if "reload" button works well from the redbox
5. Verify that "Show Perf Monitor" option works as expected. On Android >=6 re-install the app to see it ask for overlay permission at the moment when perf monitor option gets selected.
- SYSTEM_ALERT_WINDOW permission will no longer be required on Android to display Redbox
This change can break things for framework users who provide custom implementation of DevSupportManager interface on Android:
- **Who does this affect**: Owners of apps that use custom implementation of DevSupportManager interface on Android.
- **How to migrate**: Update `create` method of your `DevSupportManager`'s factory to take `ReactInstanceManagerDevHelper` type as a second argument instead of `ReactInstanceDevCommandsHandler`. The interface `ReactInstanceDevCommandsHandler` has been renamed to `ReactInstanceManagerDevHelper` but kept all the methods the same (new method got added). If you were calling one of three methods from `ReactInstanceDevCommandsHandler` interface (`onReloadWithJSDebugger`, `onJSBundleLoadedFromServer` and `toggleElementInspector`) you can call exact same methods directly on `ReactInstanceManagerDevHelper` instance that is being provided in exchange for `ReactInstanceManagerDevHelper `.
- **Why make this breaking change**:
This PR adds a new method to `ReactInstanceManagerDevHelper` called `getCurrentActivity`. In which case the prev name can no longer be justified. The activity is required for some of the DevSupportManager methods in order to start new dialogs and popups so that overlay permission isn't necessary.
- **Severity (number of people affected x effort)**:
Relatively small (perhaps Fb internally is using DevSupportManager abstraction to provide an alternative implementation but since it isn't documented I doubt anyone else uses it). Effort it very low as it boils down to updating uses of interface `ReactInstanceDevCommandsHandler` with `ReactInstanceManagerDevHelper` (all the methods in `ReactInstanceDevCommandsHandler` stays the same)
Closes https://github.com/facebook/react-native/pull/16596
Differential Revision: D6256999
Pulled By: achen1
fbshipit-source-id: 551d449e831da3de466726ead172608527fcfbb4
Miguel Jimenez Esun
Spencer Ahrens
Michael Schneider
Valentin Shergin
Peter van der Zee
Ben Nham
Taras Tsugrii
Alex Dvornikov
Sam Goldman
Héctor Ramos
Max Sherman
Yujie Liu
Marc Horowitz
Ayush Sood
Alexey Lang
Jean Lauliac
Paco Estevez Garcia
Eli White
Andrew Imm
Rahul Ramachandran
Rafael Oleza
Greg McGary
Nat Mote
Shin-Kai Chen
Ramanpreet Nara
Oleg Lokhvitsky
David Vacca
Brian Shin
Krzysztof Magiera