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 LC. hero@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 _______________________________________________ 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
