I'm trying to put together a complication for my app, I'd like to have it potentially display different images depending on the content of the complication entry but am not sure how best to handle this.
I've got a complication group added to my watch extensions asset catalogue but it only seems to have slots for a single icon in multiple versions, for complication family and device size. I'm presuming this one that is linked to my watch's complication group is only for use by placeholder content, but then as you construct this template yourself I'm not sure why it has this project setting association with a group.
As I would like to add around 10-15 icons to choose from do I need to add multiple complication image sets to my watch app assets? Last years WWDC video on creating complications was early and had them working with images directly instead of image sets, but for the different watch sizes etc I'm presuming image sets are the preferred way to go about this.
Thanks for your help in advance, cheers!
At the moment it seems I'm able to work with normal images that are shared in my app between my iOS app, today widget and watch app. They work ok at the moment, but I'm not sure if they're the right way to go about it as they're definitely not the right size for complications being 30,60, and 90 pixels depending on the scale they're targeting. Still not entirely sure what the complication set is for in the assets as they don't seem to match the image size outlined in the apple guidelines for complications
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
I have a lot of FlexLayout element in my template and it is so slow on iOS devices.
i replaced that with StackLayout and now it became little fast than before.
I'd like to know which Layout Container is fastest layout in Nativescript.
There is never one right solution for all various needs, which is why we always have options and that applies to layouts in {N} too.
Learn more about layouts interactively at nslayouts.com and choose the one that suits your use case.
If you show use what exactly you are trying to achieve, we may able to give you some suggestion. There are some general guidelines you may have to follow for better performance,
Avoid nested layouts
Use GridLayout when you need known number of partitions in your UI, the less the number of partitions are, the better the performance would be. Use FlexboxLayout otherwise.
If you just want to stack items in vertical or horizontal order, StackLayout may be a good option. Use FlexboxLayout only when you want to use flex box specific features, like when items has to be wrapped to next line, change order of items etc.,
Try to not use StackLayouts just for the shake of borders around, since you can add border to the component itself.
If you have really complicated heavy UI components, you may load it once the page has completed navigation, that may be faster.
Prefer ListView over Repeater / for loop as much as possible.
By following the above at least I can confirm, I don't hit performance issues in my apps where I have 100s of elements and 10s of partitions on screen. If you still face issues, try creating a Playground example where we can see the issue.
I noticed this same thing with FlexboxLayouts on IOS where I was doing animations with the layouts. It worked great on Android, but was very slow on IOS. I switched it to a GridLayout, and things worked a lot better.
Assume I have two png pictures and I want to make a third one by overlapping them (like a watermark effect), and save the result on the disk. Are there some libraries for react-native to implement this?
Yes. You can use react-native-view-shot https://github.com/gre/react-native-view-shot . This is mainly for taking a screenshot of the view. The Layouting and overlapping can be done in react-native. If you need blurring etc, you need to make use other libraries such as react-native-blur etc
I’ve been thinking a while about the best solution and as much as I read I get more and more confused. There are a lot of different libraries and helpers (most of them are outdated or for CI 1.x) and I really need your help.
I have a custom CMS based on CodeIgniter 2.1.3, news site that has about 40-50 images on the home page, but 80% of them are really small thumbnails in 3 different sizes and the other 20% of the images on the home page are in 2 sizes + for the inner pages when I list the news from a category there is 1 size of thumbnails. So in total I will need the original image for the news story, + 5-6 thumbnails sizes for the home page.
What’s the smartest way to deal with this? There will be let’s say 10-50 new news per day.
Is it still better to create 5-6 thumbnails per image during the upload?
What about the method “on the fly”? I’m more into this method, as I read, only the first visitor will call the library/helper to generate the thumbnails, and for the others the thumbnails will be already created so it won’t waste CPU. What about this method? Is it good practice?
What caching techniques I should use for these what I need?
Also I forgot to ask, how the other CMS system deal with generating the thumbnails? I mean about Wordpress, Drupal, Joomla, etc.
Do they store predefined sizes or generate them on the fly?
I guess their logic should be the best, or maybe not, but I want to implement something smart in my CodeIgniter CMS.
I didn’t mention, but I think it’s not important to this, I use Grocery CRUD for the admin panel.
Any help is appreciated.
Your best bet is to create images on the fly + use CDN like Amazon Cloudfront to cache the resized versions of your source image.
I’ve been using CodeIgniter for a number of years to build websites where lots of different sizes of images are used throughout the website. At the beginning I used to create every size needed out of the original image during the upload process (could easily end up with more than 5 thumbnails). This proved to be delivering the best performance – whenever you need an image of the certain size you just include it with no additional PHP processing. However I noticed that I end up with a huge number of images on the server, where the older ones may not even be used that often (e.g.: articles older than a year). Plus developing this way takes longer.
Then I started creating images on the fly, firstly using 3rd party libraries and later developed my own interface for CodeIgniter. This saves a lot of time, because during the upload process you save an original version of the image not worrying about resized versions. When displaying an image in the front end, all you normally need to do is to pass certain dimensions of the image required. Doing this way, not only you can get 5-6 versions of the image, but as many as you need. Also that’s a solution for the future when you redesign your website where the different sized images might be needed! What would you do when none of your 5 thumbnail options are no longer valid and you need different sizes?
You’re right, resizing an image on the fly can really be CPU consuming operation (especially when the large images are involved), therefore caching is a must. You can cache images right on your server or get CDN on top of that.
To keep the server tidy I normally run a cron job to delete on-the-fly images older than let's say a week. That saves space + doesn't cause harm - whenever image is needed to display, it'll just get recreated.
Check out timthumb, it's a script that resizes images on the fly and stores them in a cache. It's a simple as including an image tag with parameters in the URL.
ALso check this link which looks promising http://www.jenssegers.be/blog/31/Codeigniter-resizing-and-cropping-images-on-the-fly-continued
I love the way Drupal manage this. In Drupal 6 there was a module called imagecache (now is in core in Drupal 7, but functionality is very similar), which basically stores presets for images (image sizes, transformations, effects...) and when the visitor ask for an image the module generate different images based on presets and serve this images. This way you upload an image but have different images for different purposes.
The module has a really useful feature, if you want to change one preset, you can "flush" all the images related with that preset, so the visitors can see the changes.
Of course there are many other modules in Drupal related to imagecache or image styles, that add other effects like watermarks...
More information:
http://drupal.org/node/949222
http://drupal.org/node/163561
For software development one often needs images. But when I start working on an image I very fast end up with dozens of versions, like so
Start with a nice large scale image, let's say a photo from my camera(x.nef)
I do some adjustments on exposure correction and white balance, convert it to a x.jpg
start to add some little stuff by copying in various pieces from two other images. (a.jpg, b.jpg resulting in a layered image x.pdn
now I scale it to the required size and save it as x_small.jpg
By now I have 6 different image files floating around, and nobody but me knows the process behind them.
So the question is: How do you handle images in the development process?
Edit:
Thx for all the great input. I combined various questions to my own personal best answer. But I accepted jiinx0r's answer because it really contained the missing idea for me to apply a naming convention for the kind of changes done.
You could just put your images under source control.
That would handle the revision history and notes. If you really need to keep all the transitional versions of the image around and don't want that in your project folder, most source control trees have a 'tools' area for that type of thing.
EDIT:
If what you're after is keeping track of the various sizes (thumbnails, etc), I would go with convention over configuration and implement a uniform file (or directory) naming system.
For instance, I would probably have seperate folders for the 100px and 500px versions of the same image. Or maybe I would put them in the same folder with a special naming convention: logo-100.jpg, and logo-500.jpg ...Either way is probably fine, just make a decision and be sure to stay consistent throughout the project.
One last thought: some folks like to include a ton of metadata in the file name. To me it depends on the scope of your operation and your individual needs. I would personally default to a less is more approach -- if you're thinking about investing in maintaining something like that (or creating a tool to do it for you), make sure it's actually a net gain of time and not just something for your OCD to filddle with!
As developers, we do tend to make glaring mistakes in this area. I know I've been guilty a bunch of times.
file naming should be handled via a naming convention.
{name}-{mod type}-{size}-{version}-{create date}.png
{name}-final.png
e.g.
file-white_balance-800x600-v01-20090831.png
file-white_balance-800x600-v02-20090831.png
file-final.jpg
the real point is to create an agreed on convention that people see the value in following
(however simple/complex is necessary for your group). In my organization we do this for input/output datafiles, images, scripts, etc. (not the same convention necessarily for all, but that they follow something that was agree upon)
Hope that helps.
I try hard to have only a single "source" image and then pour all the changes into a short Python script or some other piece of code so that I can recreate the effects and/or adjust them any time later.
The original image is saved either as PNG or TIFF (to avoid quality loss due by saving) and converted into the final type as the very last step. That's also the time when I do the scaling and other lossy operations.
We developed a downloadable and a web game with a few hundred graphic assets, most of which were stored as psd files during development. We needed jpg and and png versions for the release version of the game and lower quality jpg and png versions for the web version.
We checked the originals into source control to handle versioning.
In order to remain flexible and able to alter the original without having to re-pack the image twice after each update, we had a Perl / ImageMagick script that would update the packed images automatically.
The file name remained the same, but the compressed images would go to different directories, depending which version of the game each image was packed for.
We typically have the image title and resolution appended together in the name.
myimage_800_600.png
this way all of the like images are grouped together in the folder view and you can easily select the size you want without having to wander what "medium" means.
I agree in that source control might be your best bet for this. However conventional source control doesn't really fit images.
Have you looked at http://www.alienbrain.com ?
It's commercial but may be something that could help. I was also looking and saw something about Photoshop or Imageready having version control in it too. You could look into that.
I put all the bits and pieces together from the various answers, for a system that fits my needs:
Images go into source control. This includes images of or intermediate steps.
If multiple images are needed based on one source image, but with different transformations, this can be integrated into automatic builds (scaling, compressing, tinting)
Based on a naming convention or folder structure files can get categorized into: source (e.g. original photo), intermediate (for the various processing steps), base (an image that is actually used in the software or possible after automatic processing as in step 2)
For the processing steps, a naming convention should ensure that the kind of processing can be recognised, and also the order of steps. So one would be able to move from the source image through the various processing steps to the final image.