James Hurley wrote:
But I find that the forced screen refresh does not work when running the
revlet in the browser.
To see this, open the following Web site to run the stack in your Web
browser:
http://jamesphurley.on-rev.com/DisplayProblem/test.html
There are two cards. On the first a ball bumps along across the screen.
It should run smoothly.
It seems to me that both problems aren't because of a delay, they are
because the engine is running so fast. A simple unlock of an already
unlocked screen gets skipped right over in a flash. For the first card,
using "move grc 'ball' to 610,10 in 3.5 seconds" works well.
On the second card a sentence is displayed slowly one character at a
time across a field. Instead it jump along, several characters at a time.
Since unlocking the screen happens too fast to cause a delay, I used
"wait 1 millisecond with messages" instead. In the IDE that works fairly
well. It was still too slow for a revlet, but increasing the wait to 3
or 5 milliseconds got the right results.
These problems may be cause by the same interference problem between Rev
screen refresh rate and the browsers refresh rate.
It acts like there's no interference at all. The IDE has a lot of extra
messaging going on, the revlet does not. Using a better "braking" system
fixes it. When possible, it's better to use commands that were created
specifically to control moving objects (i.e., card 1 does better with
the "move" command) and where that isn't possible a longer wait time is
necessary. The revlet is running full-bore without that.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
