Optimizing for small Android devices

[Mark Waddingham]

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.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps