CompositorType Android Performance

[Sannyasin Brahmanathaswami]

we are having some issues with performance of our new app on Android, moving from one card/stack to another or dynamically updated the interface on the same card…) without navigating to another card or stack) can take 3-5 seconds,

Turning on the accelerated rendering of a stack causees it to crash when navigating from one stack (B)  to another (A) , when we issue a command to dynamically update the interface of stack A on returning to that card. ( Bug confirmed with HQ but no resolution yet.)

So I went hunting and found an old thread on the forums, which also discusses Android performance related to compostorType settings.

There's been no more discussion since  Apr '16

http://forums.livecode.com/search.php?sid=192d835ccba0ebcb501a069f71a7a11c

I'm working on Mac and when I query the stack with msg box I get a compositorType setting of "coreGraphics" but I'm not setting that.

there is earlier discussion on the forum thread about explicitly setting compositor to openGL, tilesize and cache limit etc.

another post there sounds exactly like what we are experiencing

"I'm not sure if this is related - but on Android I was recently experiencing a big delay in re-drawing a new card (with associated animations) when switching between cards. After a lot of experimentation I was able to solve this by turning Accelerated Rendering OFF. If I really needed AR (it turns out that I don't in my current project) I'd experiment with turning it off on close card, then on again after open card."

but no resolution or robust recommendations after that…

Any updates on this sphere, learned best practices and experiences for Android?

App requirements are

1) dynamically redrawing sub-groups of a main group on click  of one subgroup (whole group is rebuilt-card redrawn)
2) moving from one stack  (b) back to another (a) where stack (a) has it's main scrolling group rebuilt.

This all works fine on iOS and also Nexus5, but we may be deployed on smaller android devices…so looking to optimize as best we can.

BR