Optimizing for small Android devices

[Sannyasin Brahmanathaswami]

Mark: Wow, yes, it does help! I hope you had a great Christimas and are refreshed ready to face all of us again (smile)

Your entire email should be posted to some knowledge base somewhere!

As for speed optimization:

-----
Alternate images

I will make 1 X images right away for my home "portal" screens heros which are now 2 X and rename the current ones to 

Looks like that should be
hero at medium.jpg  # exact size of the image object as defined in points/pixel in LC.
hero at extra-high # for the 2X version

Prepare (command):  yes this could help in a number of instances, I will try it. 

----------

Further questions

… you are right, we are not doing a lot of intensive data processing. My quick run with script profiler showed that some operations I thought we hurting the app were in fact taking a trivial amount of time. which means we can focus on the graphics, clearly the "problem." . I scoured the dictionary, but could not find any method determine amt device RAM, which I suppose is mute since the user could open as many apps as he likes and push the device to the wall, leaving little for LC… and there is nothing we can do about that.   

RE: image cache?  This is new info to me… Very unlikely we would exceed the default 64 MG for mobile. But that default makes one wonder. Because we are told that the max RAM allotted to an app on Android is 57MB…so if the total MB of images used on a card < 64… and we navigate to another stack or card in the same stack… does the cache retain images from the previous card, stack? If so then eventually the cached images will overtake the available RAM on the device if we leave it at the default.  is that correct?  If so,  then it means we *should* be doing some calculations and lowering the cache limit for Android. which again is "new info…."  

Also what if you are heading into a module/stack which is graphic intensive ?  Like our word puzzle in the app and other possible "mini games in a stack" …  if all previous images are cached, would it make sense to deliberately flush the cache before we start creating our puzzle (takes snap shots of fields, saves these as images and then distributes them as "tiles" across the card… )  if so, how does one do that? I don't see a flush cache command…

RE: Multiple Instances of same graphic/image on Card?  OK we are generating "lists" using a Parent Group with subgroups as "rows" (like DataGrid) where these Rows" contain image… in some case we are using a SVG Widget to show a few icons in the row.. these are attached to a template group on card 2… replicated over and over again down the screen dynamically on cd 1… There may be contexts where the repeated grc is  
a) a button with file on disk assigned as icon 
b) or just an image referenced by the template group that is on disk.

OK so now the card has 100 rows… with multiple instances of the exact same: SVG icon (as widget the same one icon) OR multiple button(s) with the same img file as icon OR a small image which has multiple instances on the card but each references the same, one only file on disk.  I presume this question applies to the DataGrid as well. (which I have yet to use…) 

I think the question is obvious: are all these little visual reps of a single graphic a) occupying only the value of (1 X (their un compressed size) in RAM  or does the RAM now hold ( N (number of appearances on the card) X (their uncompressed size) as a cumulative total in RAM?

RE: images streamed to the app from a server in advance with "Load" ? ….  are these cached automatically or should we load and prepare each one after it arrives?

RE:  acceleratedRendering, Navigation across stacks and Redraw issues?

please see  

http://quality.livecode.com/show_bug.cgi?id=20810

which is rather urgent as we went live on Google Play and I need an update that fixes this asap.

FWIW here is the entire handler that does almost all the work of navigation across many modules(stacks) (and many more to come)  could you re-write this for us to what you would consider the optimal SOP/ best practice, using Go in window… where 

AcceleratedRending is 
a) one in the stack we are closing
 b) needs to be turned on in the stack we are opening…

I could try myself, but frankly, I would rather you give us the "bottom line" method here if you would not mind as I'm getting a bit tired of wrestling with this on Android (over a year now!) impossible to debug when script run fine an d is works on iOS and desktop…

command portal_GoStack cardOrStackObject  

   put the short name of this stack into oStackName

   put "Siva-Siva-App,Journal,view_SivaSivaBrowser"  into tNoGoBackStacks

   if (sLastStack="Journal") AND (cardOrStackObject <> "Journal") then 
      # it means we are launching activity and we are not actually going
      # to the view the journal, in which case we have to be sure it closes
      put "Journal" into oStackName
   end if
   if (not  (oStackName is among the items of tNoGoBackStacks) ) then
   # save where we are coming; for the go back buttons:
      portal_SetCurrentStack oStackName
   end if
   
   if oStackName <> empty then # this is not the first run boot of portal
      deleteAllMobileControls # will destroy all except audioPlayer -- audio keeps play as the user peruses…

   # try to flush cache, clear buffer? Turn off ACR on the stack before we close it

      set the accelereratedRendering of the topstack to false 
   end if
   
   go  cardOrStackObject  

# cardOrStackObject  -- a string which is either the short name of  stack 
# or a card reference : gems  |   card 3 of "gems  

   wait 100 milliseconds with messages  # serious issues on Android if we don't use this
   close stack oStackName   
   wait 100 milliseconds with messages   # also needed before turning on ACR
   
#BR: 2017-12-24 for the journal we don't turn on ACR until some open card ops are done.
# as we don’t need it for the Browser Widget (as far as I know)
# Other stacks have their ACR turn on here and possibly also
# by the developer in the given module/stack as well… 
# is there a hit if we set ACR to true twice?  My understanding is no..
   
put "journal,view_SivaSivaBrower" into tDoNotAccelerate
   if not (the short name of the topstack is among the items of tDoNotAccelerate) then
      set the acceleratedRendering of the topstack to true
   end if   

# new stack is now open, with ACR true since we are "scrolling everywhere"  
# but we have redraw issues on Android… see screen shots in the bug report…
# Old stack still appears on screen… with "parts" of the pixel map occupied by the newly opened stack.

end portal_GoStack

Perhaps is it is as simple as this: with no waiting.

replace this:

   go  cardOrStackObject  
   wait 100 milliseconds with messages  # serious issues on Android if we don't use this
   close stack oStackName   
   wait 100 milliseconds with messages   # also needed before turning on ACR

with 

go to cardOrStackObject in window.

I'll try it, but still look for your insights.

BR