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/>[email protected]<[email protected]> On Sun, Jan 26, 2014 at 4:04 PM, Scott Rossi <[email protected]> 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" <[email protected]> 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 <[email protected]> > >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 > >[email protected] > >Please visit this url to subscribe, unsubscribe and manage your > >subscription preferences: > >http://lists.runrev.com/mailman/listinfo/use-livecode > > > > > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
