Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend ImageCache to handle Custom ImageInfo #86402

Closed
ColdPaleLight opened this issue Jul 14, 2021 · 1 comment · Fixed by #86555
Closed

Extend ImageCache to handle Custom ImageInfo #86402

ColdPaleLight opened this issue Jul 14, 2021 · 1 comment · Fixed by #86555
Labels
a: images Loading, displaying, rendering images c: new feature Nothing broken; request for a new capability c: proposal A detailed proposal for a change to Flutter customer: alibaba framework flutter/packages/flutter repository. See also f: labels. r: fixed Issue is closed as already fixed in a newer version

Comments

@ColdPaleLight
Copy link
Member

ColdPaleLight commented Jul 14, 2021

Background

We used external texture to display the images in our flutter app. On the Android platform, we draw the Bitmap onto the SurfaceTexture, and on the iOS platform, we convert the UIImage to CVPixelBufferRef, and finally use the Texture Widget to display the image. We do this mainly based on the following considerations:

  1. We hope that any Bitmap or UIImage can be efficiently displayed to flutter app. For example, we need to customize a photo list page, but the native platform API only provide us Bitmap or UIImage as photo.
  2. Reuse the native platform image loader. the native image loader, such as Glide on the Android platform and SDWebImage on the iOS platform, have implemented a complete set of caching solutions (memory cache, disk cache) and image decoding solutions. In addition, our CDN cropping optimization is also implemented in the native image loader. We hope that flutter app can directly reuse these capabilities.
  3. Compared with ui.Image, the memory of external texture is not managed by GC, we can precisely control the timing of memory release

Use case

We are currently refactoring this solution, we want to let the external texture can benefit from the ImageCache logic.
We hope that ImageCache can no longer dependent on ui.Image, so that we can customize ImageInfo and ImageProvier to cache external texture images in ImageCache.

Proposal

let ImageCache can no longer dependent on ui.Image,then users can cache custom ImageInfo

Related code:

sizeBytes = info.image.height * info.image.width * 4;

Expected

ImageInfo add a property named sizeBytes, then ImageCache use it.

 sizeBytes = info.sizeBytes; 

Actual

 sizeBytes = info.image.height * info.image.width * 4; 
@darshankawar darshankawar added in triage Presently being triaged by the triage team a: images Loading, displaying, rendering images framework flutter/packages/flutter repository. See also f: labels. passed first triage c: proposal A detailed proposal for a change to Flutter c: new feature Nothing broken; request for a new capability and removed in triage Presently being triaged by the triage team labels Jul 14, 2021
@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 11, 2021
@ColdPaleLight ColdPaleLight added the r: fixed Issue is closed as already fixed in a newer version label Oct 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a: images Loading, displaying, rendering images c: new feature Nothing broken; request for a new capability c: proposal A detailed proposal for a change to Flutter customer: alibaba framework flutter/packages/flutter repository. See also f: labels. r: fixed Issue is closed as already fixed in a newer version
Projects
None yet
2 participants