Trouble with graphics display in OS X
klaus at major-k.de
Thu Jan 13 12:02:10 EST 2005
> Thanks to all who responded with advice. Right now I don't see a
> I am aware that the components of the location are integers. But in
> the line:
> Set the loc of graphic "ball" to theXYcoordinates
> RR will truncate the components of theXYCoordinates and set the loc of
> the graphic to the integer poitns.
> In my applications, the coordinates are computed, for example the x
> and y coordinates of a planet moving around the sun and will therefore
> not generally be integers.
> Unfortunately the move command requires integer input. (I have asked,
> as a feature request, that RR do the truncation in the engine as
sorry, but it looks like i am not getting the point...?
Why not use the "round" function to supply integers for your handler?
> it does for set loc. I don't know if this has been implemented in RR
> 2.5.) If I were to use the "move" command it would be necessary to
> include a truncation step in the handler and this shows things up
> quite a bit. But even with integers, the move command is much slower
> than set loc.
Setting the loc is "instantly", moving includes a REAL movement, even
if the distance is ridiculously small ;-)
AND "move" depends on the current "movespeed", if not used with "in...
xx time" see below...
> For example:
> on mouseUP
> put the ticks into tstart
> set the loc of grc "ball" to 100, 100
> put 1 into dx
> put 1 into dy
> put the loc of grc "ball" into tBallLoc
> repeat 500
> add dx to item 1 of tBallLoc
> add dy to item 2 of tBallLoc
> set the loc of grc "ball" to tBallLoc -- Takes 34 ticks
> --move grc "ball" to tBallLoc without messages-- Takes 266 ticks
> --wait 1 millisec --using this and set loc takes 84 ticks
> end repeat
> set the loc of grc "ball" to 100,100
> put the ticks - tStart & return after field "data"
> end mouseUP
> But I think Malte has the answer. Yes, I am using one of the first G4
> PowerBooks. But it may be something much more sinister than just a
> poor graphics card.
> I put some busy work into the repeat loop to see if this would give RR
> time to make the display. For example
> Repeat 1000 times
> add 1 to temp
> end repeat
> But the motion was still herky-jerky, and displayed the graphic only
> at a few screen locs.
> I'm getting in way over my head here, but I wonder whether there may
> be a problem in RR in the screen refresh. When I insert the wait 1
> millisec line into the repeat loop, the graphic is displayed uniformly
> throughout the motion. But the busy work above does not create the
> same effect. Is it possible that there is a screen refresh after a
> wait command but perhaps not after a set loc command? As I say, I am
> in over my head here.
Why not use:
set the loc of grc "ball" to 100, 100
put 1 into dx
put 1 into dy
put the loc of grc "ball" into tBallLoc
add 500 to item 1 of tBallLoc
add 500 to item 2 of tBallLoc
move grc "ball" to tBallLoc in 973 millisecs
## or 1.2 secs or whatever...
## this will be equal on ANY machine, since "move... in..." will try to
compensate the different
## CPU speeds! May look a bit jerky on slower machines but the graphic
will "arrive in time" ;-)
I may overseeing something obvious!
Maybe not ;-)
klaus at major-k.de
More information about the Use-livecode