Summary:
Changelog: [Internal]
When Paper loads images. it calls with with `clipped` being set to NO.
https://github.com/facebook/react-native/blob/master/Libraries/Image/RCTImageView.mm#L346
We should do the same in Fabric as it can result in different images being loaded.
Reviewed By: JoshuaGross, shergin
Differential Revision: D22185286
fbshipit-source-id: 04afafee67fdfac53e9d17f5edeaf9b9317c7a22
Summary:
We are moving towards 100%-prettified files. That's the first step when we apply Clang Format for `ReactCommon`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20110895
fbshipit-source-id: 0a0ce4997cf1c3721b0b07ef78c1a57ce87d20f9
Summary:
Changelog: [Internal]
This allows to block queue until image is fetched.
In paper, the photo of dog will not appear unless the network request is "fast enough".
{F228670428}
Reviewed By: shergin
Differential Revision: D19907906
fbshipit-source-id: 98d68abf1255388f9b97fb9da367d8f583a4220d
Summary:
Added basic hook to enable image instrumentation. The hook passes information to the existing image loader, where instrumentation is done, specific for each app, if any.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19047899
fbshipit-source-id: 6c013806cce98bcf1ea240d696a7ede9697e5cd9
Summary:
The `RCTImageURLLoaderWithAttribution` protocol historically only returns a cancellation block to cancel the url request. But for more complex instrumentation, we may need to associate a requestId for the specific URL request. To do this, the protocol now returns an object that has both the unique ID and the cancellation block, so that instrumentation logic can refer to the ID in the future.
Note that the `RCTImageURLLoader` protocol is unchanged, because the request ID is only relevant for instrumentation purpose.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19047900
fbshipit-source-id: cd029f2470c32fc7bffd674b09a5353fe1dbc80b
Summary:
Changelog: [Internal]
For attribution purpose, pass in the surfaceId and let the app-specific image loader handle it.
Reviewed By: shergin
Differential Revision: D18494106
fbshipit-source-id: e22ca339a2dd12c5bd619b596c7db9c49dc111d0
Summary: Hiding casting madness and complexity behind a helper function to avoid bugs and improve maintainability.
Reviewed By: sammy-SC
Differential Revision: D17923549
fbshipit-source-id: 105891d85b0412fa4a17d7ae8a9e156fc1b151fb
Summary: Seems RCTImageLoader is not thread-safe, so we need to compensate for this for now. Classic RN mostly accesses the loader from the main thread (non-concurrently), so it mostly works for Paper.
Reviewed By: mdvacca
Differential Revision: D15867574
fbshipit-source-id: 4aad5570b57a136aa0bbe31d65f1afe2ae6e380e
Summary:
... and slighly new behaviour for one of them.
The method does nothing if given `key` already exists in the container.
This diff finishes the transition of ContextContainer from an internal bag of things with unclear yet ownership into a legit dedicated dependency injection container for the product code.
The original names of methods imply that the container can have only one object of a given type which is no longer true. The new API is much more generic and idiomatic to C++, it mimics `std:map` API which is intuitive to anyone who familiar with C++ containers.
Besides the naming, `insert` method changed the semantic a bit; now it does nothing in case of inserting an object with a key that already exists. That might seem counterintuitive for "normal" people, but C++ has some wired reasons for that and, hopefully, it's expected behavior in the C++ community.
Fun fact: We need this to fix hot-reload.
Reviewed By: sahrens
Differential Revision: D15681736
fbshipit-source-id: 194f342528446a911eaf072ba3a94a5d8af3cb52
Summary:
First of all, seems it's the right thing to do. Fabric C++ code is cross-platfrom and should run on *all* platforms including Windows, Linux, and Mac.
While we don't have a real *production* use cases where we need compilation for desktops, having CXX target is really handy for two reasons:
* It simplifies local test running process. Instead of going to `/fbandroid/` and executing something like `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:coreAndroid` (note the suffix). We can just do `buck test fbsource//xplat/js/react-native-github/ReactCommon/fabric/core:core` everywhere and it works now out of the box. Running tests with "Apple" flavor never worked for me.
* It allows creating synthetic benchmark tests (using Google Benchmark) that can be used as a rough approximation of code micro-optimizations.
Reviewed By: JoshuaGross
Differential Revision: D15608678
fbshipit-source-id: d2449035685dbca6ab983480f5334ec4ac11cd35
Summary:
ImageLoader is an actual external dependency, not a ImageManager.
That change allows to remove dependency on ImageManager from SurfacePresenter and make some other code simpler.
Reviewed By: mdvacca
Differential Revision: D15242047
fbshipit-source-id: 8622d15b8fdb5c3a7e25091adf7be1108f87ecd5
Summary:
This changes fix small perf problem in RCTImageManager (and layout!) saving (in my completly non-scientific tests) up to 2 ms.
Maybe that's not much, but it fires during layout (and ShadowNodeTree reconsiliation processes), so it has to be very performant.
Reviewed By: JoshuaGross
Differential Revision: D14072077
fbshipit-source-id: 0baa54584dc3ae6a5f43be13fd152b84801c8539
Summary:
Sometimes, when we deal with ImageRequest and ImageResponseObserverCoordinator we subscribe for status (or access the coordinator) without owning an ImageRequest. In those cases, we have to retain the coordinator explicitly.
For those cases, ImageRequest now exposes `ImageResponseObserverCoordinator` as a `std::shared_ptr`.
Eg, concretely in the code, `completionBlock` and `progressBlock` copied a raw pointer to the observer inside which can lead to a crash when ImageRequest is being deallocated before we received an image data.
Reviewed By: JoshuaGross
Differential Revision: D14072079
fbshipit-source-id: e10120bc05bf685e288f7b3d69092714dcd91d43
Summary: Don't use shared_ptr in this case, it's not needed.
Reviewed By: shergin
Differential Revision: D13965413
fbshipit-source-id: ec98c13f53c7d558a0cb68cea0f97568dd202cd8
Summary: Folly promises/futures have been replaced by an observer model which keeps track of loading state. This resolves at least one crash that I can no longer repro and simplifies the code a bit (IMO).
Reviewed By: shergin
Differential Revision: D13743393
fbshipit-source-id: 2b650841525db98b2f67add85f2097f24259c6cf
Summary: We are moving to more stable APIs removing all mentiones of the effort name from the codebase.
Reviewed By: mdvacca
Differential Revision: D12912894
fbshipit-source-id: 4a0c6b9e7454b8b14e62d419e9e9311dc0c56e7a
Summary: ImageManager is used to update the LocalData of Image views, as part of this process we call ImageManager::requestImage in cross platform code. Event if Android doesn't use ImageRequest we need to return an empty non-operation version of this object.
Reviewed By: shergin
Differential Revision: D10429663
fbshipit-source-id: 3621ece72f7291e2e6ab6a84b238ac16b595fc18
Summary: This diff fixes the release of ImageRequest object. The responseFutureSplitter_ can be destroyed by the time ~ImageRequest is executed. See P60163877 for original crash (this crash was reproducible when reloading or closing a Fabric screen that contains several images.
Reviewed By: shergin
Differential Revision: D10282207
fbshipit-source-id: 4f0894959e54f6d15b98e216df102e764866e387
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary:
All code styles are terribly ugly. We have the only choise - choise something and embrace it.
This particular code style was borrowed from a neibour Fabric-friendly project because it follows established Facebook guides and respects client-side traditions.
Reviewed By: mdvacca
Differential Revision: D10218598
fbshipit-source-id: 8c4cf6713c07768566dadef479191661c79988f0
Summary: This diff adds support for image views in Android
Reviewed By: shergin
Differential Revision: D9757712
fbshipit-source-id: 8d33e04c8ac4a670af6ca49bb3b9dccc69d52e40
Summary:
The spec says that `bridge_transfer` indicates that we "transfer ownership of the pointer" to ARC which implies that as soon this part of the code does not need the object, it will be deallocated. However, that's not what we want here. This object is actually already owned by another ARC-powered code somewhere else and the pointer to it was transferred as a raw pointer through the C++ world.
So, we want to keep the ownership of the object on the other side but still imply the lifetime of the object. So how can we do that? Simple, we have to use `bridge`.
Why? ARC is not magical, it's just automatic ref counting. And I think the only difference between `bridge` and `bridge_transfer` is how many refcounter's bumps will be added to the generated code. In the case of `bridge_transfer` it is zero, in the case of `bridge` it is one. So, initializing a new Objective-C variable that points to the shared resource we have to bump the counter once, so we have to use `bridge`.
Reviewed By: mdvacca
Differential Revision: D9819405
fbshipit-source-id: 9e7af343917ec4407a64d884402b10ee2a8097f9
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
@public
ImageManager coordinates all work related to loading image bitmaps for <Image> component.
The particular iOS implementation uses RCTImageLoader from RCTImage module under the hood.
Reviewed By: fkgozali
Differential Revision: D8526571
fbshipit-source-id: a0d927972d30113eed6e0cd169fceee17610181d
Samuel Susla
Paige Sun
Valentin Shergin
Kevin Gozali
Andres Suarez
Joshua Gross
Uladzislau Paulovich
David Vacca
Héctor Ramos