Interesting problem here - I'm making a small game using Flex 3 - now I have a static ImageAccess class, which first loads up all images and stores them in a static array for quicker access in the future.
Now since I address the physical bitmapdata without calling Clone() (for efficiency issues) and once by accident I've written directly onto the bitmapdata.
Now the weird part - Flex uses some kind of weird caching and stores the bitmap with the new changes made to it - no matter what I do (restart Flex Builder, delete my cache, restart browser) the bitmap data is still loaded with the extra info (even though the image is without all that data).
Please help :D
Can you give more details about what extra info you're talking about?
Correct me if I'm wrong but Flex doesn't cache anything as such, the browser does, in any case , viewing with another browser should display the original image. If it doesn't , you may consider the possibility of some forgotten function still acting on the original bitmap... have you tried viewing the application in another browser by the way?
there's also the possibility of the original image being corrupted for whatever reason...
Related
I am displaying images from the internet in a vertical ListView. I fetch the images using http.get (not using cached network image cuz I do not want to cache the images). Then I insert the image Uint8List into image.memory(). What happens is that as the user scrolls the list and images are loading, the ram keeps increasing until the whole app crashes. Any ideas what to do ?
Yeah, this is the normal behavior. I don't know why exactly. My theory is that the images by default are disposed if the dart objects holding references to them are garbage collected rather then when the widgets are knocked off the widgets tree, but don't take my word for it- that's just my personal reasoning. It may be completely wrong.
To get around this, I use Extended Image pakcage It's constructors take a bool clearMemoryCacheWhenDispose which disposes of images in RAM in scroll lists. You may do that or visit the package code to see how he's doing it, and replicate it.
Other advice I can give is to make sure your images are of the appropriate size. If you are loading your images locally check this part of the documentation to have different dimensions selected for different screen sizes https://flutter.dev/docs/development/ui/assets-and-images#loading-images
If you are fetching your images from network which is more likely, make sure their sizes are appropriate, and have different sizes served if you can. If you don't have control over that set cacheWidth and cacheHeight in Image.memory these will reduce the cached image in memory (RAM). You see by default Flutter caches images in full resolution despite their apparent size in the device/app. For example if you want your image to display in 200x200 box then set cacheWidth to 200 * window.devicePixelRatio.ceil() you will find window in dart:ui, and if you only set cacheWidth, the ratio of your images will remain true. Same true if you only set cacheHeight. Also do use ListView.builder as suggested.
I am disappointed at how little is said about this in Flutter docs. Most of the time people discover this problem when their apps start crashing. Do check your dev tools regularly for memory consumption. It's the best indicator out there.
Cheers and good luck
I was having the same issue and found a fix thanks to #moneer!
Context:
Users in my app can create shared image galleries which can easily contain several hundred images. Those are all displayed in a SliverGrid widget. When users scrolled down the list, too many images were loaded into RAM and the app would crash.
Things I had already implemented:
Image resizing on the server side and getting the appropriate sized images on the client based on the device pixel ratio and the tile size in the gallery
I made sure that my image widgets were properly disposing when out of view, but the memory size kept building up as the user scrolled through all the images anyway
Implement cacheHeight to limit the size of the cached image to the exact size of the displayed image
All these things helped but the app would eventually still crash every time the user scrolled down far enough.
The fix:
After some googling I stumbled upon this thread and tried the extended_image_package as #moneer suggested. Setting the clearMemoryCacheWhenDispose flag to true fixed the issue of the app crashing as it was now properly clearing the images from memory when they were out of view. Hooray! However, in my app users can tap on an image and the app navigates to an image detail page with a nice Hero animation. When navigating back the image would rebuild and this would cause a rebuild 'flicker'. Not that nice to look at and kind of distracting.
I then noticed that there's also an enableMemoryCache flag. I tried setting this to false and that seems to work nicely for me. The Network tab in Dart DevTools seems to show that all images are only fetched from the network once when scrolling up and down the gallery multiple times. The app does not crash anymore.
I'll have to more testing to see if this leads to any performance issues (if you can think of any please let me know).
The final code:
ExtendedImage.network(
_imageUrl,
cacheHeight: _tileDimension,
fit: BoxFit.cover,
cache: true, // store in cache
enableMemoryCache: false, // do not store in memory
enableLoadState: false, // hide spinner
)
I had a similar issue when I loaded images from files in a ListView.
[left-side: old code, right-side: new code]
The first huge improvement for me: not to load the whole list at once
ListView(children:[...]) ---> ListView.builder(...).
The second improvement was that images are no longer loaded at full-size:
Image.file("/path") ---> Image.file("/path", cacheWidth: X, cacheHeight: Y)
These two things solved my memory problems completely
Ideally caching happens kind of by default after some conditions are fulfilled. So its upon your app to be responsible to handle and control how the caching will happen.
Checkout this answer
https://stackoverflow.com/a/24476099/12264865
Is there a way to programmatically free Image resources in nativescript-vue?
I can't use the RadListView or ListView in some situations because they have issues properly rendering some of my more-complex components. Instead, I'm using a ScrollView. Now my view renders correctly, but after a while the app runs out of memory due to all the images that are loaded (as the user scrolls more images are loaded).
I'd like to free memory for images that are not visible on the page. I know how to calculate when the image is off the page, but don't know how to remove or replace the element to free the memory.
Everything I've read says to use small images (I'm already optimizing them) and then the GC will cleanup resources that are no longer used. However, the images are still technically in use until the user navigates away from the page or I can find a way to remove them from the page.
we are a bit confused how device cache is working and how it is suppose to be working. Images with an original resolution smaller than what is specified in the request do not seem to be cached at all and every time we call RequestImageForAsset looks like the image is always pulled from the cloud.
When it happens, it also shows an interesting behavior that we did not see it documented. Although RequestImageForAsset callback does not return an error, the expected produced UIImage is nil. The only way to get an image is to request it again with a smaller size.
Photos showing this behavior are shown in "Photos app" with a white dot. Only after forcing a zoom in by double clicking it, that dot disappears and only after that moment we are able to request it properly through RequestImageForAsset.
Any help is welcome
cheers
Manuel
The caching behavior (due to my testing) depends on many factors:
1) if the user has set "Optimize Storage" or "Keep originals" in the Photos Settings
2) How much space is available on the device.
In short: I would not assume any caching behavior. Just use the supplied methods of PhotoKit to request the data/image of the asset.
I have to disagree with you. You have to understand how local cache works to:
1 - according to what you are doing in your app, take some decisions like if you should cache photos yourself
2 - understand the difference between a bug an a feature. Photokit looks nice. However, its implementation has been showing a lot of issues (true bugs) and things like changing from 8.0 beta 5 to 8.0 release master recently added / camera roll which exposes some internal confusion
I use MvxImageViewLoader for MvvmCross Xamarin applications.
This component is really great and simplifies the images loading pretty much, but it (at least, out-of-the-box) is pretty basic and most of modern applications require some reacher functionality, for instance, loading/progress images or images nice appearing/transitions (possibly with custom animation).
I see there is DefaultImagePath property, but that's static image, which I can probably use by default, but that's not animated view or something.
So, is there any way to customize/extend the loader behaviour (for default image appearing, images transition (from default to loaded)) etc?
And also I've noticed that the loader caches the image and even if I trigger bound property changing (leaving the image url the same) it does not refresh the image. I guess, "caching" really means caching and so on, but what if I need to change the user icon or something... how can I forse the cache refreshing with the image loader?
Thank you!
So, is there any way to customize/extend the loader behaviour (for default image appearing, images transition (from default to loaded)) etc?
No - advanced features like fade-in/fade-out/animated-placeholder display aren't supported within the standard MvvmCross image view, and no-one that I know of has provided any samples or tutorials about how this can be done.
For adding such functionality, you can use normal software techniques - inheritance, aggregation and cut, copy, paste. e.g. you could simply create your own AgatImageView which had the behaviour your app requires based on MvxImageView.cs.
Some examples of creating your own data-bound controls is given in N=18 and N-19 of http://mvvmcross.wordpress.com/
As you already mentioned in upper comments you may use default iOS' UIActivityIndicatorView for showing progress and you should hide the progress in afterImageChangeAction, you can check if UIImageView.Image field is not null, to make sure that the image is loaded.
Regarding the caching, it's not that easy here. By default MvxImageViewLoader relies on MvvmCross framework's implementation of IMvxFileDownloadCache interface. This interface has only one public method RequestLocalFilePath(), so even if you get an instance from IoC container (Mvx.Resolve()) you won't be able to clean-up the existing cache (to do that you need to reset private _entriesByHttpUrl field of MvxFileDownloadCache class).
If you really need this, you have to copy-paste existing MvxFileDownloadCache class and make your tweaks. But I am not sure about your use-cases where you need this. If you download images from the web, the URL of the image is a sort of a key in the cache, so if you need to reload just change the URL.
Maybe you could use some old-school approach like adding GET parameters to the URL: http://mydomain.com/images/myimage.jpg?timestamp=123456. Usually this helps everywhere :-). Although I didn't test it with MvxImageViewLoader, it's just my best guess.
I’m building a mobile web application, and even though I’m still in a prototyping kind of the process, I’m having a hard time fixing certain performance problems.
The application itself (works all smooth in desktop browsers, but significantly sluggish in Mobile Safari): Hancards webapp prototype. You may login as mifeng:wangwang or create a new user.
The overall clumsy performance could be tolerable though, except for one thing: the browser simply crashes (!) when you open a set page, tap ‘view’ (enlarge all cards) and then try to go back to the previous page.
The code that gets executed when ‘view’ is tapped is this (very sluggish by itself as well; any way to improve it?):
if ($(this).hasClass('big')) {
$('.card').unwrap().removeClass('big flippable').addClass('small');
$(this).removeClass('big');
}
else {
$('.card').wrap('<div class="bigCardWrap" />').removeClass('small').addClass('big flippable');
$(this).addClass('big');
}
And another thing, a pretty weird bug. Very often the ‘word of the day‘ block won’t display the text node for the last element (<div class="meaning">), even though it’s in the code. The text will not show unless you ‘shake’ the DOM anyhow (unticking and ticking back one of the associated CSS properties can also achieve that). This happens in both desktop and mobile Safari browsers.
The code that writes it in there is this:
// While we are here, also display the Word of the day
$.post('ajax.php', {action: 'stuff:showWotd'}, function(data) {
// Decode the received data
var msg = decodeResponse(data);
// Insert the values
$('.wotd .hanzi').text(msg.content[0]['hanzi']);
$('.wotd .pinyin').text(msg.content[0]['pinyin']);
$('.wotd .meaning').text(msg.content[0]['meaning']);
});
I don’t expect you to advice me on how to fix the performance of the whole application (I will probably have to revise the overall scope of the project instead of trying to find workarounds), but I at least would like to see how to solve these two problems. Thank you!
The only performance issue I see in the script is the wrap/unwrap calls - adding and removing elements from the DOM tends to be fairly slow, and you can probably get the same effect by always having a wrapper element and changing its class rather than adding or removing it.
However, the performance issues you are seeing are most likely in your css:
3D transforms can be much faster than 2D due to hardware acceleration. It looks like you already have this, though you do need to be careful about which elements it is applied to
Shadows have real performance issues, especially when animated. Removing them will probably fix most of the slowness.
Rearranging background images can help - A single background image under transparent pages is faster than having a background image for each page.