Go to card [with effects] is slow on Android

[Roger Eller]

Scott,

I thought the new graphics engine was supposed to fix all the graphics
speed problems.  I also considered throwing everything into a scroller, but
I'm too invested in what I've built so far to change it now.  On my next
project, perhaps I'll try that.

~Roger


Roger EllerGraphics Systems Analyst

803 North Maple StreetP: 864.967.1625Simpsonville, SC 29681C: 864.908.0337
SealedAir.com <http://www.sealedair.com/>Roger.E.Eller at SealedAir.com<roger.e.eller at sealedair.com>




On Sun, Jan 26, 2014 at 4:04 PM, Scott Rossi <scott at tactilemedia.com> wrote:

> Hi Roger:
>
> Unfortunately, the built-in transitions always seem laggy.  I don't know
> for sure what's going on under the hood (bonnet?) but I imagine LC is
> essentially creating screenshots of the current screen and destination
> screen before executing the transition, and then generating the transition
> effect with those images.  Combine this with the fact that most mobile
> screen transitions are controlled by a swipe gesture where you can
> partially swipe halfway across the screen, stop, and swipe back -- and
> you'll quickly see that you can't recreate native transition behavior
> using LC's built-in effects.
>
> The limitations of built-in effects are compounded by the fact that only
> one transition can occur at a time, while both iOS and Android often do
> multiple transitions in multiple regions of the screen simultaneously.
>
> Native mobile scrollers seem to operate in a similar fashion (using a
> capture of the region to scrolled), but appear to be more optimized.  One
> way (and it's likely an unrealistic way) to get closer to a more native
> user experience would be to build all the screens of your app as subgroups
> of one master group on a single card, with each subgroup spaced out the
> width of the screen, add a horizontal native scroller, and use the paging
> behavior of the native scroller to navigate between groups.
>
> Of course, this is probably a solution for folks with strong thresholds
> for pain and still plenty of hair on their heads.  Memory could be an
> issue (both machine and human).
>
> If somebody has a better solution for getting good native screen
> transitions, I would love to see it.  :-)
>
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 1/26/14 8:19 AM, "Roger Eller" <roger.e.eller at sealedair.com> wrote:
>
> >Scott and Jacque,
> >
> >I have combined parts of both of your advisements, plus one from the
> >MobGUI
> >forum.  I didn't mention that my buttons are "Option groups" (acting as
> >buttons), so I replaced the hilite part with:
> >
> >send "mouseDown" to group "Option1" -- only changes which option in a
> >cluster is selected
> >
> >Overall, it feels a bit faster than before, but still laggy compared to
> >other apps I've downloaded from the Google Play Store.  Thank you for the
> >tips!
> >
> >~Roger
> >
> >
> >On Sun, Jan 26, 2014 at 2:42 AM, Scott Rossi <scott at tactilemedia.com>
> >wrote:
> >
> >> Hi Roger:
> >>
> >> One place to start might be the click.  Why do you have a click
> >>occurring?
> >>
> >> Regards,
> >>
> >> Scott Rossi
> >> Creative Director
> >> Tactile Media, UX/UI Design
> >_______________________________________________
> >use-livecode mailing list
> >use-livecode at lists.runrev.com
> >Please visit this url to subscribe, unsubscribe and manage your
> >subscription preferences:
> >http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>