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.
BR
On 9/23/17, 5:21 AM, "use-livecode on behalf of Dan Friedman via use-livecode"
<use-livecode-boun...@lists.runrev.com on behalf of
use-livecode@lists.runrev.com> 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.
-Dan
_______________________________________________
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
