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
h...@medium.jpg  # exact size of the image object as defined in points/pixel in 
hero@extra-high # for the 2X version

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


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 

RE:  acceleratedRendering, Navigation across stacks and Redraw issues?

please see

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


go to cardOrStackObject in window.

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


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: Optimizing for small Andro... Mark Waddingham via use-livecode
    • Re: Optimizing for small ... Sannyasin Brahmanathaswami via use-livecode

Reply via email to