Summary:
Under rare and as-yet-to-be determined circumstances, images can sometimes fail to load/download and get "stuck", without producing an error.
Because the `RCTNetworkTask` for these images is stuck in the "in progress" state, they clog up the RCTImageLoader task queue, which has a limit of 4 concurrent in-progress tasks.
This was previously masked by the fact that we automatically cancelled image requests when the RCTImageView moved offscreen, but we no longer do that.
This diff adds logic to detect some types of stuck task and remove them, thereby unblocking the queue. I've also restored the functionality of cancelling downloads for offscreen images (but not unloading the image itself) so that stuck images will be cancelled when you move to another screen, instead of using up space in the queue forever.
Reviewed By: fkgozali
Differential Revision: D3398105
fbshipit-source-id: 75ee40d06a872ae8e1cb57f02f9cad57c459143c
Summary:
Now that we no longer have a separate NetworkImageView implementation, we can remove that code path from Image.js
I've also moved the prefetch method into RCTImageViewManager for consistency with the getImageSize method, which means we no longer need to export the RCTImageLoader module to js.
Reviewed By: javache
Differential Revision: D3398157
fbshipit-source-id: fbbcf90a61549831ad28bad0cb3b50c375aae32c
Summary:
As per https://twitter.com/olebegemann/status/738656134731599872, our use of "main thread" to mean "main queue" seems to be unsafe.
This diff replaces the `NSThread.isMainQueue` checks with dispatch_get_specific(), which is the recommended approach.
I've also replaced all use of "MainThread" terminology with "MainQueue", and taken the opportunity to deprecate the "sync" param of `RCTExecuteOnMainThread()`, which, while we do still use it in a few places, is incredibly unsafe and shouldn't be encouraged.
Reviewed By: javache
Differential Revision: D3384910
fbshipit-source-id: ea7c216013372267b82eb25a38db5eb4cd46a089
Summary:
Allows developers to specify headers to include in the HTTP request
when fetching a remote image. For example, one might leverage this
when fetching an image from an endpoint that requires authentication:
```
<Image
style={styles.logo}
source={{
uri: 'http://facebook.github.io/react/img/logo_og.png',
headers: {
Authorization: 'someAuthToken'
}
}}
/>
```
Note that the header values must be strings.
Works on iOS and Android.
**Test plan (required)**
- Ran a small example like the one above on iOS and Android and ensured the headers were sent to the server.
- Ran a small example to ensure that \<Image\> components without headers still work.
- Currently using this code in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7338
Reviewed By: javache
Differential Revision: D3371458
Pulled By: nicklockwood
fbshipit-source-id: cdb24fe2572c3ae3ba82c86ad383af6d85157e20
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Reviewed By: javache
Differential Revision: D3365373
Pulled By: nicklockwood
fbshipit-source-id: 66d149eb80c5c6725311e1e46d7323eec086ce64
Summary: The decoded image cache was previously static, meaning that cached images could persist beyond the lifetime of the module. This resulted in some flakiness in the RCTImageLoaderTests due to the loader returning cached image instanced from previous tests instead of the correct instance.
Reviewed By: bestander
Differential Revision: D3346329
fbshipit-source-id: 375af8894cef1c5b6303c6cdfd7eb57ebcfe3251
Summary:
Some apps are complaining about flashing images when performing navigation transitions. An example issue would be:
1. Load a master list view with many images
2. Click on an image to go to a detail view
3. Go back to the master list view
At step (3), users see a number of images flash from a placeholder image back to the final image because `-[RCTImageView didMoveToWindow]` calls `clearImage` when the image view exits the view hierarchy between (1) and (2) and calls `reloadImage` (which sets the image property asynchronously) when the image view re-enters the view hiearchy between (2) and (3).
This diff fixes the issue by being less aggressive about clearing image contents. It only clears image contents when the app receives a memory warning or the app goes into the background.
For comparison, CKNetworkImageComponent in ComponentKit doesn't have this purging behavior at all.
Reviewed By: javache
Differential Revision: D3325009
fbshipit-source-id: efca10099cdfdb49afbb3f550854d4b8a40511d0
Summary:
In RN we cache image data after loading/downloading an image, however the data we store is the compressed image data, and we decode this asynchronously each time it is displayed.
This can lead to a slight flicker when reloading image components because the decoded image is discarded and then re-decoded.
This diff adds a small (5MB) cache for decoded images so that images that are currently on screen shouldn't flicker any more if the component is reloaded.
Reviewed By: bnham
Differential Revision: D3305161
fbshipit-source-id: 9969012f576784dd6f37d9386cbced2df00c3e07
Summary:
This works with D3305161 to minimize image flashing. After D3305161, the completion handler passed to `-[RCTImageLoader loadImageWithoutClipping:size:scale:resizeMode:progressBlock:completionBlock:]` may be called back on the main queue in the case of a cached image. In this case, we want to set the image view's image property synchronously rather than on the next runloop iteration via dispatch_async. This minimizes the amount of image flashing the user sees when displaying a cached image.
The exception to this case is for blurred images. A blur can be an expensive (taking multiple ms on the CPU), so we always make sure to perform the blur off the main queue even if the image is cached and the callback came back on the main queue.
Reviewed By: nicklockwood
Differential Revision: D3310176
fbshipit-source-id: 6820782527b65e4956879cf06e8ed2c09c622a58
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary:
`tintColor`, even in style, works on Android; this must be some old comment but that confused me when reading the docs.
**Test plan:**
- Launched website locally
Closes https://github.com/facebook/react-native/pull/7465
Differential Revision: D3278166
fbshipit-source-id: 4e986e0f2a9ba05de4404b93d28687596fbb4fad
Summary: Fixed a crash where making a network request with unrecognized/unsupported scheme would crash by attempting to insert a nil RCTNetworkTask into an array.
Reviewed By: javache
Differential Revision: D3275810
fb-gh-sync-id: be208c6bf87d882209901b850dcc25da4ba79a08
fbshipit-source-id: be208c6bf87d882209901b850dcc25da4ba79a08
Summary: To prevent layout popping, when inserting images inside text we would render a blank placeholder image while the real image was loading. It turns out that this isn't necessary, as we can just specify the size of the image without having an actual image to display.
Reviewed By: javache
Differential Revision: D3212766
fb-gh-sync-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
fbshipit-source-id: e98851b32a2d0ae809fc0a4be47e6b77f3b17996
Summary:Split out from PR #4252 - kmagiera I've made the changes to how the radii arrays are allocated, is the approach I've taken correct? also it looks like ImageStylePropTypes are needed so I left them in for the moment. I suppose this pull request will only be valid if iOS supports image corner radii, but at least it's here if/when needed. Attached an image of how it handles the existing case:
Closes https://github.com/facebook/react-native/pull/5197
Differential Revision: D3138725
Pulled By: mkonicek
fb-gh-sync-id: df772fd07fe85386ae4c681f9e79a19d2316d38b
fbshipit-source-id: df772fd07fe85386ae4c681f9e79a19d2316d38b
Summary:Adds `Image.prefetch` to prefetch remote images before they are used in an actual `Image` component. This is based off of #4420 by sospartan and skevy's work.
Closes https://github.com/facebook/react-native/pull/6774
Differential Revision: D3153729
Pulled By: bestander
fb-gh-sync-id: ef61412e051a49b42ae885edce7905a8ca0da23f
fbshipit-source-id: ef61412e051a49b42ae885edce7905a8ca0da23f
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:Adds a `center` option to `Image`'s `resizeMode` prop, which doesn't enlarge images.
This is how it looks in UIExplorer:
{F60386921}
Reviewed By: dmmiller
Differential Revision: D3064284
fb-gh-sync-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
shipit-source-id: 79cd2da8f44c5b3da2e42d3bebf3131335f53c28
Summary: This diff introduces a blur radius property to the Image component on ios. If the radius specified is greater then 0 then native will apply a blur filter to the image
Reviewed By: nicklockwood
Differential Revision: D3054671
fb-gh-sync-id: d7a81ce5a08a3a2091c583f5053c6a86638b21b2
shipit-source-id: d7a81ce5a08a3a2091c583f5053c6a86638b21b2
Summary:When using the `Image` component with a `src` property instead of `source` the component fails silently. vjeux suggested to add a warning (https://twitter.com/Vjeux/status/704509214937317378).
Tested with the UIExplorer example on iOS and Android simulators.
Closes https://github.com/facebook/react-native/pull/6221
Differential Revision: D3011659
Pulled By: mkonicek
fb-gh-sync-id: c9bae6c802c173ef85d9c4552747db994c58906e
shipit-source-id: c9bae6c802c173ef85d9c4552747db994c58906e
Summary:Initializing native modules can block the main thread for tens of milliseconds when it starts up, making it difficult to instantiate the bridge on demand without causing a performance blip.
This diff splits up the initialization of modules so that - although they still happen on the main thread - they don't block the thread continuously.
Reviewed By: javache
Differential Revision: D2965438
fb-gh-sync-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
shipit-source-id: 38c9c9d281e4672b5874d68b57d4c60d1d268344
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary:Images cropped using the ImageEditor were always given an alpha channel, even if opaque.
This causes them to be saved as PNGs instead of JPEGs (increasing memory and bridge traffic) and also causes unnecessary blending when they are drawn.
Reviewed By: fkgozali
Differential Revision: D2982682
fb-gh-sync-id: b65f361efd78e35f259836111b38d914bae49847
shipit-source-id: b65f361efd78e35f259836111b38d914bae49847
Summary:Diff D2647083 cleaned up image editing related logics and introduced an image cropping bug.
The bug is that the result of the image cropping will be wrong if displaySize is specified.
In particular, in Ads Manager App, we generate thumbnail by calling the image cropping function with displaySize set.
With this bug, the thumbnail we get is not correct.
This diff fixed the bug by replacing `image` with `croppedImage`. It should be a typo from D2647083
Reviewed By: zjj010104
Differential Revision: D2947730
fb-gh-sync-id: df7c7f3ddac5b053425db884f808e27b8418116e
shipit-source-id: df7c7f3ddac5b053425db884f808e27b8418116e
Summary:
should use UIGraphicsEndImageContext rather than UIGraphicsGetCurrentContext
public
Reviewed By: nicklockwood, chaceliang
Differential Revision: D2875657
fb-gh-sync-id: 0fa059e2da3d0bb1ffe5fe50a1bdaeddafc2bbfa
Summary:
After the release of 0.14, static images should be placed in the source code tree and then required as explained in the [Images guide] (https://facebook.github.io/react-native/docs/images.html). This pull request updates the image documentation and examples to the new asset system. UIExplorer tested on iOS and Android.
Closes https://github.com/facebook/react-native/pull/4987
Reviewed By: svcscm
Differential Revision: D2796276
Pulled By: bestander
fb-gh-sync-id: 732ffa2f136391bb8a3e40a54b5b1ff5022c97f2
Summary:
In Android, Fresco's default rounding corners support mode is BITMAP_ONLY which doesn't work in all cases (such as animated GIF's, some scale types, etc.).
Specifying the new "overlayColor" property on an Image will cause Fresco to switch to the other rounding corners mode, OVERLAY_COLOR, and will draw rounded corners by overlaying the solid color specified.
Fresco's behaviour is explained here: http://frescolib.org/docs/rounded-corners-and-circles.html
Closes https://github.com/facebook/react-native/pull/5366
Reviewed By: svcscm
Differential Revision: D2854696
Pulled By: mkonicek
fb-gh-sync-id: 251701ee8a64acbfc22694e9d4661c40eef75725
Summary:
public
Previously, `<Image>` elements embedded inside `<Text>` ignored all style attributes and props apart from `source`. Now, the `width`, `height` and `resizeMode` styles are observed. I've also added a transparent placeholder to be displayed while the image is loading, to prevent the layout from changing after the image has loaded.
Reviewed By: javache
Differential Revision: D2838659
fb-gh-sync-id: c27f9685b6976705ac2b24075922b2bf247e06ba
Summary:
public
Standardises the image decoding logic for all image sources, meaning we get the benefits of efficient downscaling of images from all sources, not just ALAssets.
Reviewed By: javache
Differential Revision: D2647083
fb-gh-sync-id: e41456f838e4c6ab709b1c1523f651a86ff6e623
Summary:
public
React Native currently exposes the iOS layer shadow properties more-or-less directly, however there are a number of problems with this:
1) Performance when using these properties is poor by default. That's because iOS calculates the shadow by getting the exact pixel mask of the view, including any tranlucent content, and all of its subviews, which is very CPU and GPU-intensive.
2) The iOS shadow properties do not match the syntax or semantics of the CSS box-shadow standard, and are unlikely to be possible to implement on Android.
3) We don't expose the `layer.shadowPath` property, which is crucial to getting good performance out of layer shadows.
This diff solves problem number 1) by implementing a default `shadowPath` that matches the view border for views with an opaque background. This improves the performance of shadows by optimizing for the common usage case. I've also reinstated background color propagation for views which have shadow props - this should help ensure that this best-case scenario occurs more often.
For views with an explicit transparent background, the shadow will continue to work as it did before ( `shadowPath` will be left unset, and the shadow will be derived exactly from the pixels of the view and its subviews). This is the worst-case path for performance, however, so you should avoid it unless absolutely necessary. **Support for this may be disabled by default in future, or dropped altogether.**
For translucent images, it is suggested that you bake the shadow into the image itself, or use another mechanism to pre-generate the shadow. For text shadows, you should use the textShadow properties, which work cross-platform and have much better performance.
Problem number 2) will be solved in a future diff, possibly by renaming the iOS shadowXXX properties to boxShadowXXX, and changing the syntax and semantics to match the CSS standards.
Problem number 3) is now mostly moot, since we generate the shadowPath automatically. In future, we may provide an iOS-specific prop to set the path explicitly if there's a demand for more precise control of the shadow.
Reviewed By: weicool
Differential Revision: D2827581
fb-gh-sync-id: 853aa018e1d61d5f88304c6fc1b78f9d7e739804
Summary:
https://github.com/facebook/react-native/issues/3679 was only partially fixed as the behaviour only works on iOS. This implements the same behaviour for Android. If the JSBundle was loaded from the assets folder, this will load images from the built-in resources. Else, load the image from the same folder as the JS bundle.
EDIT: For added clarity:
On iOS,
Bundle Location: 'file:///Path/To/Sample.app/main.bundle'
httpServerLocation: '/assets/module/a/'
Name: 'logo'
type: 'png'
**Resolved Asset location: '/Path/To/Sample.app/assets/module/a/logo.png'**
On Android,
Bundle Location: 'file:///sdcard/Path/To/main.bundle'
httpServerLocation: '/assets/module/a/',
name: 'logo'
type: 'png'
**Resolved Asset location: 'file:///sdcard/Path/To/drawable_mdpi/module_a_logo.png'**
Closes https://github.com/facebook/react-native/pull/4527
Reviewed By: svcscm
Differential Revision: D2788005
Pulled By: mkonicek
fb-gh-sync-id: 3f6462a7ee6370a92dd6727ac422c5de346c3ff1
Summary:
public
This diff adds a `getSize()` method to `Image` to retrieve the width and height of an image prior to displaying it. This is useful when working with images from uncontrolled sources, and has been a much-requested feature.
In order to retrieve the image dimensions, the image may first need to be loaded or downloaded, after which it will be cached. This means that in principle you could use this method to preload images, however it is not optimized for that purpose, and may in future be implemented in a way that does not fully load/download the image data.
A fully supported way to preload images will be provided in a future diff.
The API (separate success and failure callbacks) is far from ideal, but until we agree on a unified standard, this was the most conventional way I could think of to implement it. If it returned a promise or something similar, it would be unique among all such APIS in the framework.
Please note that this has been a long time coming, in part due to much bikeshedding about what the API should look like, so while it's not unlikely that the API may change in future, I think having *some* way to do this is better than waiting until we can define the "perfect" way.
Reviewed By: vjeux
Differential Revision: D2797365
fb-gh-sync-id: 11eb1b8547773b1f8be0bc55ddf6dfedebf7fc0a
Kasim Tan
Nick Lockwood
Maarten Schumacher
Hedger Wang
Adam Comella
Ben Nham
Corné Dorrestijn
Jimmy Mayoukou
Christoph Pojer
Howard Yeh
mattds
James Ide
Nick
Marc Horowitz
Alon Schwarz
Reem Helou
Konstantin Raev
Zahan Malkani
Varun Vachhar
David Aurelio
Rui Chen
Fada Chen
Christopher Dro
Wenjing Wang
Andreas Drivenes
Noam Bartov
sunnylqm
Geoffrey Goh
Milen Dzhumerov
Satyajit Sahoo
