New (?) display problems in RevWeb

James Hurley jhurley0305 at sbcglobal.net
Wed Jul 29 12:44:03 EDT 2009


> >
> (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






More information about the use-livecode mailing list