JS plumbing to get filters into native #44458
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D56845572 |
Base commit: be09d12 |
Summary: This works similar to how `transform` is parsed in that it sets tags on the View to actually update the prop when all the prop setters are done being called since the parsing of the array is not very trivial. Besides that it is pretty simple and just calls into `FilterHelper` and uses `setRenderEffect`: https://developer.android.com/reference/android/view/View#setRenderEffect(android.graphics.RenderEffect). That API is only exposed in version 31 of the SDK so it is gated accordingly. Reviewed By: NickGerleman Differential Revision: D54640600
Summary: tsia Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D56847475
Summary: Title says it all. Right now this ignores drop-shadow as that will be implemented later. Some of this code will need to be adjusted as it is the one filter that takes multiple amounts. But I feel that can be amended later when we get there - after all the `amount` parsing code is just casting to a float at the moment, so we are not locking ourselves into anything. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D54640629
…xt and containing block (facebook#44456) Summary: Self explanatory: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_positioned_layout/Understanding_z-index/Stacking_context#description and https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D55044674
…k#44457) Summary: Most filters are not going to work on iOS. It is a long story but essentially there is not a good way to continuously get a snapshot of the view and its descendants to filter. We can, however, implement `brightness` using `compositingFilter` and blend mode. This is really not documented at all, but if you assign a string representing the blend mode to the [`compositingFilter`](https://developer.apple.com/documentation/quartzcore/calayer/1410748-compositingfilter?language=objc) property on CALayer, it will actually work. The filter we use is [`multiplyBlendMode`](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Reference/CoreImageFilterReference/index.html#//apple_ref/doc/filter/ci/CIMultiplyBlendMode). As the title suggests this just multiplies the two layers. We can apply this to a `_filterLayer` and set its background color to the brightness amount to get the desired results. Most other color filters either operate on the color components dependently (e.g. new red component depends the value in blue and green), or they have addition operations. We can do addition with `linearDodgeBlendMode`, but the order of operations does not work (we multiply, clamp, then add vs. multiply, add, then clamp). `opacity` is just a multiplier on the CALayer `opacity` property. Changelog: [Internal] Reviewed By: NickGerleman Differential Revision: D56447175
Summary:
This is the JS plumbing to get it so that views can now use filters. The typing looks like
`filter: [{brightness: 1.5}, {hueRotate: '90deg'}]`
which is different than web which would look like `filter: brightness(1.5) hue-rotate(90deg)`. I feel like the web version is overly complicated and not very *react native-y*. Transform uses the array based approach (albeit they also accept a string). Open to changing this but really feel like the web format is silly and bad since it would just involve parsing some arbitrary string.
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn filter format into {name: string, amount: string}
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56845572
joevilches
force-pushed
the
export-D56845572
branch
from
768c309
to
c5992ea
Compare
|
This pull request was exported from Phabricator. Differential Revision: D56845572 |
|
This pull request has been merged in 0dceac9. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
This is the JS plumbing to get it so that views can now use filters. The typing looks like
filter: [{brightness: 1.5}, {hueRotate: '90deg'}]which is different than web which would look like
filter: brightness(1.5) hue-rotate(90deg). I feel like the web version is overly complicated and not very react native-y. Transform uses the array based approach (albeit they also accept a string). Open to changing this but really feel like the web format is silly and bad since it would just involve parsing some arbitrary string.The diff includes:
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56845572