Re: Go to card [with effects] is slow on Android

[Charles E Buchwald]

Hi Scott and Roger,

I've done this with an iPad app that was sort of magazine like. I grouped a 
bunch of graphics in line horizontally on one card, and used a mobile scroller 
to handle paging between them. The scrolling was beautiful, and since it was a 
relatively simple app used as a museum interactive, it wasn't that much of a 
pain to set up.

It worked well, except that I ran into the card size limit. That is, there is a 
limit to the pixel width of the stuff on the card... I think it's 32,000 px but 
I'd have to look it up or check my notes. I wasn't using retina size graphics, 
which would have made  the situation worse. The width of my total number of 
pages exceeded the limit, so I ended up with an awkward "click this button for 
more" in the middle of the scrolling to jump to a second card and set of 
images/pages.

Years ago, working on a game in SuperCard, I used a scheme that dynamically 
loaded the content for the next and previous cards/pages/images. I'm kind of 
thinking that something like that could work here... just haven't tried it yet. 
Maybe it could be a way to get around the limit.

Cheers,
- Charles

On 26 Jan 2014, at 3:04 PM, Scott Rossi  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"  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 
>> 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@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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Charles E. Buchwald
char...@buchwald.ca

___
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

Re: Go to card [with effects] is slow on Android

[Dave Kilroy]

Hi Roger (and Jaque)


J. Landman Gay wrote
> Addendum: I wasn't accounting for mobile. Both my first or second method 
> will likely pop up the keyboard briefly which would not be good. I think 
> you'll have to use the third method, which will eliminate the engine's 
> attempt to focus on any field.

Sorry I should have been less gnomic in my earlier posting...

I've encountered unwanted keyboards springing up with mobile before, and did
exactly what Jacque described (but found that I had to give the engine up to
a second before setting traversalOn to true to reliably avoid the keyboard
appearing)




-
"Some are born coders, some achieve coding, and some have coding thrust upon 
them." - William Shakespeare & Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Go-to-card-with-effects-is-slow-on-Android-tp4675089p4675138.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: 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 
roger.e.el...@sealedair.com




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

Re: Go to card [with effects] is slow on Android

[Scott Rossi]

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"  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 
>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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Go to card [with effects] is slow on Android

[Roger Eller]

This is what I ended up doing (in the card script of each card):
One card has 20 editable fields.  The others contain fewer than 10 fields.
This works to prevent the mobile keyboard from popping up automatically,
and performance is "ok".

*on* closeCard

   *set* the traversalOn of fld "flThis" to false

   *set* the traversalOn of fld "flThat" to false

   *set* the traversalOn of fld "flTheOther" to false

   *set* the traversalOn of fld "flEtc" to false

*end* closeCard


*on* openCard

   *send* editableFields to me in 125 millisecs

*end* openCard


*on* editableFields

   *set* the traversalOn of fld "flThis" to true

   *set* the traversalOn of fld "flThat" to true

   *set* the traversalOn of fld "flTheOther" to true

   *set* the traversalOn of fld "flEtc" to true

*end* editableFields


~Roger


On Sun, Jan 26, 2014 at 3:20 PM, J. Landman Gay wrote:

> On 1/26/14, 2:16 PM, J. Landman Gay wrote:
>
>> On 1/26/14, 12:47 PM, Roger Eller wrote:
>>
>>> They are all offending me.  ;-)
>>>
>>> TraversalOn (focusable) is checked for all fields the user needs to fill
>>> in.  I simply don't want any field to activate the on-screen keyboard as
>>> soon as the card opens.  I want the user to have a chance to see the
>>> whole
>>> screen and choose which field they wish to edit.
>>>
>>
>  3. If there are only a few fields, you can set the traversalOn to false
>> on preOpenCard and set it back to true after openCard is done. This
>> isn't as practical if you have a lot of fields, since you need to loop
>> through them all, but it works okay for one or two fields and there is
>> no cursor flash.
>>
>>
> Addendum: I wasn't accounting for mobile. Both my first or second method
> will likely pop up the keyboard briefly which would not be good. I think
> you'll have to use the third method, which will eliminate the engine's
> attempt to focus on any field.
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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
>
___
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

Re: Go to card [with effects] is slow on Android

[J. Landman Gay]

On 1/26/14, 2:16 PM, J. Landman Gay wrote:

On 1/26/14, 12:47 PM, Roger Eller wrote:

They are all offending me.  ;-)

TraversalOn (focusable) is checked for all fields the user needs to fill
in.  I simply don't want any field to activate the on-screen keyboard as
soon as the card opens.  I want the user to have a chance to see the
whole
screen and choose which field they wish to edit.



3. If there are only a few fields, you can set the traversalOn to false
on preOpenCard and set it back to true after openCard is done. This
isn't as practical if you have a lot of fields, since you need to loop
through them all, but it works okay for one or two fields and there is
no cursor flash.



Addendum: I wasn't accounting for mobile. Both my first or second method 
will likely pop up the keyboard briefly which would not be good. I think 
you'll have to use the third method, which will eliminate the engine's 
attempt to focus on any field.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Go to card [with effects] is slow on Android

[J. Landman Gay]

On 1/26/14, 12:47 PM, Roger Eller wrote:

They are all offending me.  ;-)

TraversalOn (focusable) is checked for all fields the user needs to fill
in.  I simply don't want any field to activate the on-screen keyboard as
soon as the card opens.  I want the user to have a chance to see the whole
screen and choose which field they wish to edit.


The auto-selection of the first object with traversalOn goes back to the 
dawn of the engine. I think it interferes more than it helps, and I 
rarely find the feature useful.


The engine will focus on the first object it finds that has traversalOn 
set to true. On Windows that can be either a field or a button. On Mac 
it's always a field.


Any attempt to script around it must occur after the openCard message 
fires, because the engine doesn't do the selection until after openCard.


Depending on my stack, I've used one of these workarounds:

1. Send a message in an openCard handler that will fire another handler 
after openCard is done. The interval can be very short, 1 millisecond 
should work. In the second handler you just "focus on nothing". There 
may or may be a breif cursor flash depending on the machine, but you 
have to be looking for it to see it.


2. No scripting required for this. Place an editable field on the card 
somewhere offscreen (like at -100,-100), with its traversalOn set to 
true. The engine will select that one but no one will see it. The field 
must be visible since the engine will skip over hidden fields.


3. If there are only a few fields, you can set the traversalOn to false 
on preOpenCard and set it back to true after openCard is done. This 
isn't as practical if you have a lot of fields, since you need to loop 
through them all, but it works okay for one or two fields and there is 
no cursor flash.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Go to card [with effects] is slow on Android

[Roger Eller]

They are all offending me.  ;-)

TraversalOn (focusable) is checked for all fields the user needs to fill
in.  I simply don't want any field to activate the on-screen keyboard as
soon as the card opens.  I want the user to have a chance to see the whole
screen and choose which field they wish to edit.

~Roger

On Sun, Jan 26, 2014 at 12:36 PM, Dave Kilroy
wrote:

> Roger, check whether the offending field has 'TraversalOn' set to false
>
>
___
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

Re: Go to card [with effects] is slow on Android

[Alejandro Tejada]

Hi Roger,


Roger Eller wrote
> [snip]
> I opened demoMC27_no_sounds.livecode in LC 6.5.2 RC1 and added a
> preOpenStack containing set the fullscreenmode of this stack to
> "ExactFit",
> then I clicked Test.  It opened fine on my tablet
> [snip]
> Speed was ok for a demo, but for an interactive
> app like mobile users have come to expect, the transitions still feel slow
> to me.

Could you post a download link for this APK to test in other 
Android devices?

Recently, Andy Parng published his game "Battles of Chinese Zodiac"
for iOS and Android (http://www.parng.com/cz-en.html)
and I found it too fast, even in the Basic Mode.

I will write him about this and other ideas to make
it more entertaining... :D

Thanks in advance!

Al



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Go-to-card-with-effects-is-slow-on-Android-tp4675089p4675123.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: Go to card [with effects] is slow on Android

[Alejandro Tejada]

Roger Eller wrote
> [snip]
> 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!

Change the layer mode of this group "Option1" from static 
to dynamic and test again. Post your results.

http://livecode.wikia.com/wiki/Layer_mode

Al



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Go-to-card-with-effects-is-slow-on-Android-tp4675089p4675122.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: Go to card [with effects] is slow on Android

[Dave Kilroy]

Roger, check whether the offending field has 'TraversalOn' set to false



-
"Some are born coders, some achieve coding, and some have coding thrust upon 
them." - William Shakespeare & Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Go-to-card-with-effects-is-slow-on-Android-tp4675089p4675118.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: Go to card [with effects] is slow on Android

[Roger Eller]

I have a crazy new thing happening. After arriving on a new card, a field
(not a native field) is receiving focus, and the keyboard pops up, which is
quite annoying.  I have "focus on nothing" in the go to card X script, but
that doesn't seem to help.

~Roger


On Sun, Jan 26, 2014 at 11:19 AM, Roger Eller
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 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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Go to card [with effects] is slow on Android

[Roger Eller]

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  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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Go to card [with effects] is slow on Android

[Roger Eller]

Al,

I first tried Demo.apk, and it refused to install at all on Android 4.1.1.

I opened demoMC27_no_sounds.livecode in LC 6.5.2 RC1 and added a
preOpenStack containing set the fullscreenmode of this stack to "ExactFit",
then I clicked Test.  It opened fine on my tablet, and when I got to the
screen transitions page, I was amazed.  All (yes, "ALL") of the effects
worked, yet the LC documentation claims that only a couple of effects are
compatible with Android.  Speed was ok for a demo, but for an interactive
app like mobile users have come to expect, the transitions still feel slow
to me.

~Roger


On Sun, Jan 26, 2014 at 1:12 AM, Alejandro Tejada wrote:

> Hi Roger,
>
> Some time ago, I made this APK for Android of the first
> MetaCard's demo. It includes a demo of all transition effects.
> You could install it on your Android tablet and share your results:
>
> https://dl.dropboxusercontent.com/u/3834621/Demo.apk
>
> You can download the stack in LiveCode format (not *.mc) from:
> https://dl.dropboxusercontent.com/u/3834621/demoMC27.livecode
>
> If your OS or LiveCode version have problems playing sounds
> download this version:
> https://dl.dropboxusercontent.com/u/3834621/demoMC27_no_sounds.livecode
>
> This is an old stack, so play it isolated...
>
> Al
>
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/Go-to-card-with-effects-is-slow-on-Android-tp4675089p4675091.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> 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
>
___
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

Re: Go to card [with effects] is slow on Android

[Scott Rossi]

Hi Roger:

One place to start might be the click.  Why do you have a click occurring?
 Is this to trigger code or display a hilite?  Both of these can be done
through code without doing any kind of physical/manual click.

hilite btn "xyz"
wait 150 millisecs
unhilite of btn "xyz"
dispatch "mouseUp" to btn "xyz"

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 1/25/14 8:38 PM, "Roger Eller"  wrote:

> I know that "do" is a bad idea sometimes, but in this case, my swipe code
>is in the background image, and that's where the swipe direction is
>determined, then it clicks at the loc of myButton (to show the button is
>being pressed).
>
>The only problem is that it hesitates for about a second before playing
>the
>transition effect.  What would be a more optimal way?  I like the effects,
>but the lag is killing the experience!
>
>*global* gDirection
>
>*on* mouseUp
>
>   *if* gDirection is not empty *then*
>
>  *put* "visual effect push" && gDirection && "very fast"
>intotShowEffectCommand
>
>  *do* tShowEffectCommand
>
>   *end* *if*
>
>   *go* card "card_three"
>
>   *put* empty into gDirection
>
>*end* mouseUp
>
>~Roger
>___
>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
>



___
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

Re: Go to card [with effects] is slow on Android

[J. Landman Gay]

On 1/25/14, 10:38 PM, Roger Eller wrote:

  I know that "do" is a bad idea sometimes, but in this case, my swipe code
is in the background image, and that's where the swipe direction is
determined, then it clicks at the loc of myButton (to show the button is
being pressed).

The only problem is that it hesitates for about a second before playing the
transition effect.  What would be a more optimal way?  I like the effects,
but the lag is killing the experience!

*global* gDirection

*on* mouseUp

*if* gDirection is not empty *then*

   *put* "visual effect push" && gDirection && "very fast"
intotShowEffectCommand

   *do* tShowEffectCommand

*end* *if*

*go* card "card_three"

*put* empty into gDirection

*end* mouseUp


You can avoid "do" this way:

  lock screen for visual effect
  go next
  unlock screen with visual effect "push" && gDirection && "very fast"

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Go to card [with effects] is slow on Android

[Alejandro Tejada]

Hi Roger, 

Some time ago, I made this APK for Android of the first 
MetaCard's demo. It includes a demo of all transition effects.
You could install it on your Android tablet and share your results: 

https://dl.dropboxusercontent.com/u/3834621/Demo.apk

You can download the stack in LiveCode format (not *.mc) from: 
https://dl.dropboxusercontent.com/u/3834621/demoMC27.livecode

If your OS or LiveCode version have problems playing sounds 
download this version: 
https://dl.dropboxusercontent.com/u/3834621/demoMC27_no_sounds.livecode

This is an old stack, so play it isolated... 

Al




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Go-to-card-with-effects-is-slow-on-Android-tp4675089p4675091.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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