Multitouch Picture Scale Example veeery slow on device
Hi! I've done a Multitouch Picture Scale Example some time ago: http://community.clickteam.com/showthread.php?t=67392
The problem is the speed on the device - its far away from feeling 'native', if you use real images instead of a blank colorblock like
in my example it's not workable.
does somebody maybe have a look at the code if it could get some improvements?!? so we could imitate the iphone picture gallery app?!
thanks,
It works pretty fast here. I tried using this image instead of the block you are using:
http://www.dvd-ppt-slideshow.com/blo...ckground-8.jpg
Worked full speed on my iPod 3rd generation.
Somebody mentioned in another thread that they got huge speed improvements by changing the build mode to 'Release' in XCode instead of 'Debug'.
Debug mode doesn't slow down here, but maybe it does for some people.
ok, thanks Andos, i wanna give it a try.
maybe my problem happens because i use it with different layers on a scrolling frame with 6 different images that are scaleable. (image gallery with slide function and parallax)
The runtime is optimized for having very large textures shown on the screen. It will automatically generate mipmaps (smaller versions of the graphics) that it will switch to when an image is scaled down heavily. It makes the images appear smoother with fewer artifacts. One problem this could give is memory usage. Having many large images loaded will use a lot of memory even though the images on the screen themselves don't appear to be large.
If memory is low it causes all textures to be unloaded and then on-screen images will be loaded back into memory. The problem is just that if all images are on the screen at the same time it will send the runtime into a unload-load loop (which will make the runtime very slow). It is difficult for us to change this behavior since we are required by Apple to unload resources when iOS instructs the runtime to - otherwise the app gets force closed looking like a crash.
If this is a continuous problem for some people for high-memory usage we might have to add a condition to the iOS object: "Low memory warning received".
The runtime itself already does a lot of work under the hood when this happens, but the user(you) might be able to unload more memory since you know more about how your app works than the runtime does.
Does it help to hide active objects that are out of screen?!? And make them visible, if they appears on screen (scrolling)
No MMF2 handles that already. Invisible or out-of-screen objects are not drawn no matter what.
(In)visibility does not affect memory usage if the object is visible and on-screen at some point in your game.
If an object is shown at least once then it will be in memory until the resource collector frees up unused object memory after 15 seconds of not being shown on the screen.
Posting Permissions
