CompositorType Android Performance

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

CompositorType Android Performance

Rick Harrison via use-livecode
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







_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: CompositorType Android Performance

Rick Harrison via use-livecode
On 3/1/17 9:40 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
> 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

I never did quite understand how to adjust the compositorType and the
other properties. Shortly after acceleratedRendering was introduced, LC
started applying default settings for us, and since then I haven't
bothered to change them. In fact, there's a warning in the dictionary
that unless we know what we're doing, we're better off leaving the
defaults alone. So I do.

> 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.

That's the default for Mac. They're listed in the dictionary under
acceleratedRendering.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode