Wow, you really thought of everything. Thanks Bernd! I'll try this as soon as possible.
~Roger On Jun 5, 2015 5:39 AM, "BNig" <bernd.niggem...@uni-wh.de> wrote: > Roger, > > this is probably due to the limited processing power of the android-watch > > This is similar to iOS back when I made the scrollers. At the time iPhones > had trouble mixing all the blend modes fast enough. > So I build in a cheat. The command is "makeiOSReady" it is located in the > script of the group. What it does is to make a snapshot of the scroller and > hide all the graphics. What is left on is an image "mock" and layered on > top > of this field "fDisplay-Scroll" > > For the first 3 of the clock faces try > > on mouseUp > dispatch "makeiOSReady" to group "Hours" > dispatch "makeiOSReady" to group "Minutes" > dispatch "makeiOSReady" to group "moveSeconds" > end mouseUp > > once you are done with your resizing of the groups because a resize of the > group, e.g. "hours" will remove the image "mock" and you do your resizing > on > the graphics. > That is the reason why you issue the "makeiOSReady" command at the end, > when > you are done configuring the groups. > > This should put considerably less burden on the processor of your > android-watch. > > If that does not make it work try disabling the card script that set the > color. > > Also you may play with the wait x milliseconds with messages that is issued > twice, once in mouseUP handler and once in "advanceSeconds" handler of the > start/stop button > > send "setWheel tHours + 1" to group "hours" > send "setWheel tMinutes + 1" to group "Minutes" > send "setWheel tSeconds + 1" to group "moveSeconds" > > wait 5 milliseconds with messages -- increase the milliseconds to > wait, gives more time. > > What I see in the video is very much what took me long to debug and which > turned out to be the wait... being too short. > > Note, "makeiOSReady" only works on the non-egg shaped scrollers. For > egg-shaped scrollers I could look into them next week when I am back from a > weekend trip and see if I could tweak them to work more efficient. But > there > is a lot of computation going on behind the scene. > > Try these suggestion in the given order and see what makes it work. Please > tell us if you get it to work. > > Kind regards > > Bernd > > > > Roger Eller wrote > > Bernd, > > > > I finally found a few minutes to play. I think possibly the layerMode > may > > need a tweak to get smooth movement on Android. It looks great and > smooth > > on the computer. Here's a video of the first run on my watch. > > > > > https://dl.dropboxusercontent.com/u/54789013/Android/SmartQ/LordEllerWatch.MOV > > > > ... and this is the shrunken stack (last modified in 6.6.2). > > > https://dl.dropboxusercontent.com/u/54789013/Android/SmartQ/LordEllerWatch_0_2.livecode.zip > > > > ~Roger > > > > > > -- > View this message in context: > http://runtime-revolution.278305.n4.nabble.com/Clock-tp4692455p4692972.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