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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
