Commit Graph

4 Commits

Author SHA1 Message Date
Xin Chen 0975e96d53 Fix transform when calculate overflowInset
Summary:
This diff fixes overflowInset calculation when a shadow node has transform matrix from a transfrom prop in JS. Specifically, this fixed the use case when transform directly used on a view component. When using Animated.View, it will create an invisible wrapper which will behave correctly with existing logic. This diff bring both use cases to work properly.

When a shadow node has transform on it, it will affect the overflowInset values for its parent nodes, but won't affect its own or any of its child nodes overflowInset values. This is obvious for translateX/Y case, but not for scale case. Take a look at the following case:

```
     ┌────────────────┐                 ┌────────────────┐                      ┌────────────────┐
     │Original Layout │                 │  Translate AB  │                      │    Scale AB    │
     └────────────────┘                 └────────────────┘                      └────────────────┘
                                                        ─────▶           ◀─────                  ─────▶
┌ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ┐     ┌ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ─ ┐      ┌ ─ ─ ─ ─ ─ ┬──────────┐─ ─ ─ ─ ─ ┐
        │ A        │                      │ A        │                             │ A        │
│       │          │        │     │       │          │          │      ├ ─ ─ ─ ─ ─ ┼ ─ ─┌─────┤─ ─ ─ ─ ─ ┤
 ─ ─ ─ ─│─ ─ ─┌───┐┼ ─ ─ ─ ─              │          │                   ◀─ ─ ─    │    │AB   │  ─ ─ ─▶
│       │     │AB ││        │     │ ┌ ─ ─ ┼ ─ ─ ─ ┬──┴┬ ─ ─ ─ ─ ┤      │           │    │     │          │
        └─────┤   ├┘                      └───────┤AB │                            └────┤     │
│             │┌──┴─────────┤     │ │             │   │         │      │ │              │ ┌───┴──────────┤
              ││ABC         │                     │┌──┴─────────┐                       │ │ABC           │
│             │└──┬─────────┤   │ │ │             ││ABC         │    │ │ │              │ │              │
┌───ABD───────┴─┐ │             │                 │└──┬─────────┘    │   ▼              │ └───┬──────────┘
├─────────────┬─┘ │         │   │ │ ├───ABD───────┴─┐ │         │    │ ├────────────────┴──┐  │          │
 ─ ─ ─ ─ ─ ─ ─└───┘─ ─ ─ ─ ─    ▼   └─────────────┬─┘ │              ▼ │      ABD          │  │
                                  └ ┴ ─ ─ ─ ─ ─ ─ ┴───┴ ─ ─ ─ ─ ┘      ├────────────────┬──┘  │          │
                                                                        ─ ─ ─ ─ ─ ─ ─ ─ ┴─────┴ ─ ─ ─ ─ ─
```

For the translate case, only view A has change on the overflowInset values for `right` and `bottom`. Note that the `left` and `top` are not changed as we union before and after transform is applied.

For the scale case, similar things are happening for view A, and both `left`, `right`, and `bottom` values are increased. However, for View AB or any of its children, they only *appear* to be increased, but that is purely cosmetic as it's caused by transform. The actual values are not changed, which will later be converted during render phase to actual pixels on screen.

In summary, overflowInset is affected from child nodes transform matrix to the current node (bottom up), but not from transform matrix on the current node to child nodes (top down). So the correct way to apply transform is to make it only affect calculating `contentFrame` during layout, which collects child nodes layout information and their transforms. The `contentFrame` is then used to decide the overflowInset values for the parent node. The current transform matrix on parent node is never used as it's not affecting overflowInset for the current node or its child nodes.

This diff reflects the context above with added unit test to cover the scale and translate transform matrix.

Changelog:
[Android/IOS][Fixed] - Fixed how we calculate overflowInset with transform matrix

Reviewed By: sammy-SC

Differential Revision: D34433404

fbshipit-source-id: 0e48e4af4cfd5a6dd32a30e7667686e8ef1a7004
2022-03-01 14:33:04 -08:00
Andrei Shikov 1953f6f02e Exclude raw props from view shadow nodes
Summary:
With the `MapBuffer`-based props calculated from C++ props, there's no need to keep `rawProps` around for Android views.

This change makes sure that the `rawProps` field is only initialized under the feature flag that is responsible for enabling `MapBuffer` for prop diffing, potentially decreasing memory footprint and speeding up node initialization as JS props don't have to be converted to `folly::dynamic` anymore.

For layout animations, props rely on C++ values, so there's no need to update `rawProps` values either.

Changelog: [Internal][Android] - Do not init `rawProps` when mapbuffer serialization is used for ViewProps.

Reviewed By: mdvacca

Differential Revision: D33793044

fbshipit-source-id: 35873b10d3ca8b152b25344ef2c27aff9641846f
2022-02-22 17:23:05 -08:00
Andres Suarez 8bd3edec88 Update copyright headers from Facebook to Meta
Reviewed By: aaronabramov

Differential Revision: D33367752

fbshipit-source-id: 4ce94d184485e5ee0a62cf67ad2d3ba16e285c8f
2021-12-30 15:11:21 -08: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