Image size can exceeds the limit after resize, causing 'Bitmap too large to be uploaded into a texture'
See original GitHub issueI’d like to display an image as large as possible within the limit, so I decided to write code as following:
ImageRequest req = ImageRequestBuilder.newBuilderWithSource(Uri.parse(NETWORK_IMAGE_URL))
.setResizeOptions(new ResizeOptions(2048, 2048))
.build();
SimpleDraweeView v = (SimpleDraweeView) holder.itemView;
v.setAspectRatio(IMAGE_ASPECT_RATIO);
DraweeController ctrl = Fresco.newDraweeControllerBuilder()
.setOldController(v.getController())
.setImageRequest(req)
.setAutoPlayAnimations(true)
.build();
v.setController(ctrl);
When I run above code with the image whose dimension is 720px*2478px, it is not displayed on the screen but getting following logcat message:
W/OpenGLRenderer: Bitmap too large to be uploaded into a texture (630x2169, max=2048x2048)
So I checked the imagepipeline
to see what is happening in the resize procedure, found something weird in generating the numerator.
The numerator is generated In the method getScaleNumerator(ImageRequest, EncodedImage)
from ResizeAndRotateProducer
class, which calls roundNumerator(float)
to get numerator from the ratio generated from `determineResizeRatio(ResizeOptions, int, int).
While getting a numerator value from roundNumerator(float)
method, it adds extra ROUNDUP_FRACTION
to maxRatio * JpegTranscoder.SCALE_DENOMINATOR
, causing the numerator be more than the expected in some cases.
I tracked the value from each process, and the result is as follows:
In getScaleNumerator()
:
determineResizeRatio()
returned0.82647294
roundNumerator()
returned7
In doTransform()
- numerator is genrated from
getScaleNumerator()
- With the numerator
7
,JpegTranscoder
resizes the image into 7/8 of its original size, results resized one has a size of 630px*2169px.
While the final image’s height has larger than the limit (BitmapUtil.MAX_BITMAP_SIZE
), it will not be shown on the screen.
When I remove adding the ROUNDUP_FRACTION
in method roundNumerator(float)
, it generates a numerator of 6
, which resizes the image smaller than the limit(2048px), results final image size of 540px * 1859px.
Here’s a question:
- Why additional
ROUNDUP_FRACTION
is required in generating the numerator? - If adding
ROUNDUP_FRACTION
is intended and cannot be modified, how can I avoid the above error?
Issue Analytics
- State:
- Created 8 years ago
- Comments:6 (3 by maintainers)
Top GitHub Comments
Hey there , we’ve been asked to contribute on a github project as a semester task of our university (me and my teammate) and since we liked fresco a lot we decided to try to help out here! We found this issue interesting and we tried to make a progress on kunny’s work. I’m attaching our pull request that reffers on this issue! #1273
Marking as a starter-task in case anyone wants to help to get this done sooner than later.