Android performance (images)
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 73
- Joined: Mon Nov 12, 2012 4:13 pm
Android performance (images)
When using (heavy? 2.5 mb) images on Android the performance drops significantly, has anyone experienced this problem too? If so, is there a fix?
Re: Android performance (images)
Hi,
Why would you use images of 2.5MB? If you're using JPEGs, these images probably take tenfold their size in memory. If you load 10 images, the Android OS will have to free up memory to allow your process continue to run. Freeing up the memory reduces performance temporarily.
The best solution is to use smaller images. Not just in size but specifically images that need less memory. Another solution could be to set the alwaysBuffer of the image controls to true, and, if you haven't done so yet, include the images in the standalone rather than as separate files. You can also set the acceleratedRendering to true and make sure that the layerMode of the image objects is correect (depending on your needs). Unfortunately, these properties may increase startup time of the stack. Everything has its pros and cons.
Kind regards,
Mark
Why would you use images of 2.5MB? If you're using JPEGs, these images probably take tenfold their size in memory. If you load 10 images, the Android OS will have to free up memory to allow your process continue to run. Freeing up the memory reduces performance temporarily.
The best solution is to use smaller images. Not just in size but specifically images that need less memory. Another solution could be to set the alwaysBuffer of the image controls to true, and, if you haven't done so yet, include the images in the standalone rather than as separate files. You can also set the acceleratedRendering to true and make sure that the layerMode of the image objects is correect (depending on your needs). Unfortunately, these properties may increase startup time of the stack. Everything has its pros and cons.
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
-
- Posts: 73
- Joined: Mon Nov 12, 2012 4:13 pm
Re: Android performance (images)
Hi Mark,
Thanks for your extensive answer!!! We are using some pretty big images with some clear parts (interactive magazine), we followed your advice and removed these images.
We also incorporated your other tips to upgrade our app and it is now much better, but still not as fluid as our iPhone app. Surely our Android app needs some finetuning, but I think there is still a gap to be closed by Runrev for the Android platform (but that's another discussion).
Thanks for your help!
Chris
Thanks for your extensive answer!!! We are using some pretty big images with some clear parts (interactive magazine), we followed your advice and removed these images.
We also incorporated your other tips to upgrade our app and it is now much better, but still not as fluid as our iPhone app. Surely our Android app needs some finetuning, but I think there is still a gap to be closed by Runrev for the Android platform (but that's another discussion).
Thanks for your help!
Chris
Re: Android performance (images)
Hi Chris,
I often have similar problems when making apps for iPhone and Android. Android hardware simply isn't of the same quality as Apple hardware, but Android hardware is also much cheaper.
If you want to have the same speed on Android as on iOS, you need to use low-resolution pictures and crude animation. I made some animations and had to make my recursive scripts run every 400 milliseconds and make the objects move by 3 or more pixels at a time, to get the same speed as on iPhone. On iPhone, I could move the objects every 100 milliseconds by whatever (small) distance I needed and have a smooth animation.
Kind regards,
Mark
I often have similar problems when making apps for iPhone and Android. Android hardware simply isn't of the same quality as Apple hardware, but Android hardware is also much cheaper.
If you want to have the same speed on Android as on iOS, you need to use low-resolution pictures and crude animation. I made some animations and had to make my recursive scripts run every 400 milliseconds and make the objects move by 3 or more pixels at a time, to get the same speed as on iPhone. On iPhone, I could move the objects every 100 milliseconds by whatever (small) distance I needed and have a smooth animation.
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
-
- Posts: 73
- Joined: Mon Nov 12, 2012 4:13 pm
Re: Android performance (images)
Hi Mark,
Thanks for the idea, to switch to a lower resolution, maybe we will implement this option too. The devices we use for Android testing are pretty high-end (HTC One X + Sony Xperia Z), but still the performance isn't ideal. I think these devices match the performance of an iPhone or even higher, but still the performance of the app is far behind.
Kind Regards,
Chris
Thanks for the idea, to switch to a lower resolution, maybe we will implement this option too. The devices we use for Android testing are pretty high-end (HTC One X + Sony Xperia Z), but still the performance isn't ideal. I think these devices match the performance of an iPhone or even higher, but still the performance of the app is far behind.
Kind Regards,
Chris
Re: Android performance (images)
Three solutions to be had here:
1. Change your image to a smaller size.
2. Change your image compression method: PNG 8-bit if it uses only full transparency, PNG 24-bit if it needs feathered transparency, JPG if it is a photo
3. Use accelerated graphics and smaller processing tiles for compositor, prevent double-buffering of large images:
1. Change your image to a smaller size.
2. Change your image compression method: PNG 8-bit if it uses only full transparency, PNG 24-bit if it needs feathered transparency, JPG if it is a photo
3. Use accelerated graphics and smaller processing tiles for compositor, prevent double-buffering of large images:
Code: Select all
set the compositorType of this stack to "opengl"
set the compositorTileSize of this stack to 16
set the alwaysBuffer of this stack to false