Fix resizeMethod="resize" for image prefetching#54228
Closed
Abbondanzo wants to merge 1 commit into
Closed
Conversation
meta-cla
Bot
added
the
CLA Signed
|
@Abbondanzo has exported this pull request. If you are a Meta employee, you can view the originating Diff in D85200818. |
Abbondanzo
force-pushed
the
export-D85200818
branch
3 times, most recently
from
0971652 to
6c0779c
Compare
Summary: ## Issue When prefetching images with the `resizeMethod` prop set, there's a brief period of time where the image has not laid out and the dimensions are 0x0. Since `ImageSource.h` only considers the `type` and `uri` properties for equality, two different `ImageSource` objects would be considered equal despite having different `size`. We would continue on to prefetch the image in its fullest quality and retain that image in `ImageState`, and upon subsequent requests once we have non-zero layouts, we would bail out early in the `ImageShadowNode::updateStateIfNeeded` method since both the old image source and image request params are equal in this case. ## Fix Rather than adding `size` to the equality check, this change adds identical logic directly from `ReactImageView` to determine if we should postpone the image request: if the image is resizable and we don't have a width or a height, postpone! ## Additional Context I noodled with a few spots of where this should ultimately live, but this seemed like the least invasive without making some larger refactors. The other approach I considered was to instead return an optional `ImageRequest` object from `ImageManager->requestImage call` to signal that no request was ever made, and using the `ImageRequest` response as part of the equality check. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D85200818
Abbondanzo
force-pushed
the
export-D85200818
branch
from
6c0779c to
5c6b7dc
Compare
|
This pull request has been merged in 26ad949. |
Collaborator
|
This pull request was successfully merged by @Abbondanzo in 26ad949 When will my fix make it into a release? | How to file a pick request? |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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:
Issue
When prefetching images with the
resizeMethodprop set, there's a brief period of time where the image has not laid out and the dimensions are 0x0. SinceImageSource.honly considers thetypeanduriproperties for equality, two differentImageSourceobjects would be considered equal despite having differentsize. We would continue on to prefetch the image in its fullest quality and retain that image inImageState, bailing out early in theImageShadowNode::updateStateIfNeededmethod since both the old image source and image request params are equal in this case.Fix
Rather than adding
sizeto the equality check, this change adds identical logic directly fromReactImageViewto determine if we should postpone the image request: if the image is resizable and we don't have a width or a height, postpone!Additional Context
I noodled with a few spots of where this should ultimately live, but this seemed like the least invasive without making some larger refactors. The other approach I considered was to instead return an optional
ImageRequestobject fromImageManager->requestImage callto signal that no request was ever made, and using theImageRequestresponse as part of the equality check.Changelog: [Internal]
Differential Revision: D85200818