Setting the acceleratedRendering to true on startup on

Sannyasin Brahmanathaswami brahma at
Sat Sep 23 15:27:22 EDT 2017

Dan, yes this could be really helpful

Almost all (but one) use cases in our app framework are simply to facilitate either a scrolling field or a scrolling group.

If we are looking for some consistent "algorithm" for this, which I am, so we don't have so much mental-re-estate consumed every time we want use it… perhaps what works is

1) finish all inits
2) set acceleratedRendering to true at the same time we create our mobile scroller
3) set it to false the same time we delete all our mobile controls

if this actually works, then we can just add this to our lib_mobileControls.livecodescript "backscript" and it would serve us everywhere in all contexts.  Just have to be careful not to be creating any scroller inside any *open* handlers.

worth a try. Though I expect Jacque may jump in with more caveats.

Also I believe the "wait with messages"  in effect creates a condition where "the app comes to an idle"  Though I'm still not clear on this, Jacque explained it briefly once, but going back to the dictionary, even reading the entry for wait very carefully.  "wait" shows "idle" as related and "idle" shows "wait" as related, but neither indicate exactly what that means.

when we issue "wait 200 milliseconds with messages"  does the engine send idle to the card? i.e now the phone OS has time to "catch up" ?? The current understanding seems to be that Livecode can "get ahead" of the OS on Android… I mean, any app is in effect a "controller" of the OS on the machine. So it's as if we have to let Android catch up before doing anything more? sheer guess work on my part… Mark would have a better analysis.  But we are seeing another bug "resume on Android causes LC to crash" seems to be alleviated if you the stack that has a wait handle in the preopenstack handler…so I guess on Android, open handlers are firing on resume, even though it appears that you are going and coming from an already open stack… another mystery there.

Until this bug (if it is one, since it works fine in iOS I presume it is) is fixed, a precise definition of the "best hackaround" in any context will be useful, so you are getting close to that.



On 9/23/17, 5:21 AM, "use-livecode on behalf of Dan Friedman via use-livecode" <use-livecode-bounces at on behalf of use-livecode at> wrote:

    I had these exact same issues:  black screen if acceleratedRendering was enabled on Android at startup.   I found that if I set the acceleratedRendering to true after ALL startup items were complete (preOpenCard, preOpenStack, openCard, openStack, and whatever else you’re doing at launch – basically when the app comes to an idle) the acceleratedRendering then was enabled successfully and seemed to work properly from that point on.
    That’s my 2 cents.  Hope it helps.

More information about the Use-livecode mailing list