On 2017-12-27 06:04, Sannyasin Brahmanathaswami via use-livecode wrote:
Any thoughts in this area?

In terms of images / screen resolution etc...

The first thing to ensure is that *all* your images objects use the filename property rather than embedding the image data in the stackfile via the 'text' property.

One exception: if you are constructing images on the fly temporarily (i.e. for a single card) then the 'text' property is still the best choice.

The size of the image files on disk is not really relevant - what matters is the amount of memory they use to render, which is 4 bytes per pixel. (You can have a 1Kb PNG which has a decompressed size which would require many gigabytes decompressed, for example).

Filename referenced images are decompressed and cached on use - the size of the cache is determined by the 'imageCacheLimit' global property, and its current usage is the 'imageCacheUsage' property - both are in bytes.

If your image cache is too small, then there will be a 'bump' whenever an image needs to be decompressed - you can ensure images are in the cache (assuming the cache is large enough) by using the 'prepare image' command.

The engine understands @ suffixes to image filenames (before the extension!), which allow you to provide different sizes of images depending on the device pixel resolution of the device. For example, if you have lots of images which have been prepared for retina devices, then they will be being scaled down on lower resolution devices for no real gain, and will be taking more memory than need be on such devices - take a look at the (image) filename property in the dictionary which explains how that works.

By default the engine maps 1 pixel in LiveCode space to 1 logical pixel in device space. A (original!) retina device will have 2 device pixels to 1 logical pixel, whereas a non-retina device will have 1 device pixel to 1 logical pixel. For retina devices you generally want images of 2x the horz and vert size compared to non-retina to ensure maximum display fidelity.

So one thing to check is that all your images are not 'oversized' - i.e. they are the exact size needed to fit the pixel rect of the objects using them in LiveCode. Then provide @2x ones for higher resolution devices. Assuming your images are currently 'oversized' to ensure good display on high-res devices, this will save you 75% of the in-memory footprint when running on a lower-res device (i.e. not retina).

In terms of accelerated rendering...

The cache of 'tiles' used in acceleratedRendering is per-stack, and is reset on every card change. The cache is only 'in-memory' when the stack is opened. On mobile it is possible for more than one stack to be opened, they stack from most recently opened to least recently opened. So, in general, it is probably better to explicitly close stacks you are no longer using. Using the 'go in window' form of the go command (IIRC) does this for you - i.e. closes the old and opens the new, and is probably the most efficient means to move between stacks on mobile.

The amount of memory which is used by acceleratedRendering (on any one stack) is always the compositorCacheLimit of the stack. If the stack requires more tiles to render than the cache-limit allows, acceleratedRendering will not be used, and the engine will fall back to normal rasterization.

On mobile, if you are using OpenGL modes of acceleratedRendering, then (IIRC) the cache is actually the GPU RAM which is used, and not 'normal' RAM (if there is a difference these days with more flexible memory busses!). However, there is an overhead in generating the tiles - but that is only transient and is never more than the pixel size of the stack at device resolution (e.g. for a 800*600 stack non-retina - it would require a maximum temporary buffer of 800*600*4 bytes).

In terms of memory, then the above two things are pretty much the largest 'memory hog' of any application - unless you are loading large amounts of data into memory (which I don't think you would be in the case of your app - we're talking more like doing analysis of 100,000s of points of data) then any memory issues will likely be due to graphics.

Hope this helps!

Warmest Regards,


Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 
              • Re: ... J. Landman Gay via use-livecode
              • Re: ... Richard Gaskin via use-livecode
              • Re: ... Sannyasin Brahmanathaswami via use-livecode
              • Re: ... Richard Gaskin via use-livecode
              • Re: ... Richard Gaskin via use-livecode
              • Re: ... J. Landman Gay via use-livecode
              • Re: ... Sannyasin Brahmanathaswami via use-livecode
              • Re: ... Sannyasin Brahmanathaswami via use-livecode
              • Re: ... J. Landman Gay via use-livecode
              • Re: ... Bob Sneidar via use-livecode
  • Re: Optimizing for small Andro... Mark Waddingham via use-livecode

Reply via email to