>
(On Windows XP here)
Behaviour is the same in FF3.0.12, Google Chrome 2.0.172.37 and IE8.
Opera
refuses to load the revWeb plugin (I think that is something to do
with the
javascript detection routine, as I can get the samples to work in
Opera on
the runrev page - although not the main demo).
On the moving ball card, clicking either of the buttons flashes the
ball at
high speed across the card. Clicking the ball itself, the movement
begins on
the left and proceeds smoothly and slowly across. IF the mouse is
moved
(while over the revlet) during the ball movement, then the speed
increases -
not to the "almost instant" level of clicking the button, but about
4 times
the speed. If the mouse pointer is moved off the revlet to another
area of
the web page, then the speed reverts to the slow steady version.
(SNIP)
Hope that's useful.
Yes, that is helpful. Thank you. So it is not a Mac problem.
I had completely forgotten about that script within the ball itself.
It is rather convoluted (see below.)
What it does it to move the ball forward one pixel (move grc "ball"
relative 1,0 without waiting) and then responds to a "mouseStopped"
message to go back and repeat the "move relative" command. And so on
for 600 repetitions. The web version has been updated:
http://jamesphurley.on-rev.com/DisplayProblem/test.html
Apparently the revlet responds to the mouseStopped message and forces
a screen refresh, or as Jacque suggest, simply slows it down enough to
see the change on screen, omething that does not happen with the loop
through the setLoc commands or the mouseMove commands of the earlier
"rainbow" example.
I don't get any of the effects you describe in moving the mouse out of
the window. Curious.
Jim Hurley
The Ball Script:
local tLoc,i, tStartTime
on mouseUp
put the ticks into tStartTime
set the loc of grc "ball" to 10,100
put 1,0 into tLoc
set the movespeed to 65000
put 1 into i
doMove
end mouseUp
on moveStopped
if i < 600 then
add 1 to i
doMove
else
put "Movestopped" & comma\
&& the ticks - tStartTime & " ticks" &return after field 1
put the script of me into field "script"
end if
end moveStopped
on doMove
move grc "ball" relative tLoc without waiting
end doMove
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.
Jacque,
Thanks for your feedback.
I think you are right about the speed with which the stack runs as a
weblet. I'm not so sure about the IDE being the culprit. I saved the
stack as a stand alone, and it runs at about the same speed as a
standalone as it does running in the IDE. Why is there such a large
speed increase in the revlet over that in the standalone? Very
strange. But not unwelcome. Just need to harness this newfound speed.
And there is still the VERY slow response in the Rainbow stack--see:
http://jamesphurley.on-rev.com/Rainbow/test.html
Dragging the flashlight is lethargic and occasionally, the image
itself breaks up.
Thanks again,
Jim Hurley
>
> 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 | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
