Mark Smith wrote:
David, you may well have been down this route, but the following little
experiment I found quite interesting:
on mouseUp
put the millisecs into t0
show img "alex"
unlock screen
put the millisecs into t1
repeat
if the millisecs >= t1 + 30 then
hide img "alex"
unlock screen
put the millisecs into t2
exit repeat
end if
end repeat
put t1 - t0 && t2 - t0 && t2 - t1
end mouseUp
The 'unlock screen' meant that I always actually saw the image (I
believe it forces a screen refresh), and the repeat loop guarantees (I
think) that the image is visible for at least 30 ms.
The timing measurements were (on my 1.5Ghz G4 laptop):
t1 - t0 9 to 20
t2 - t0 45 to 60
t2 - t1 reliably 36 +- 1
No idea if this is helpful, but I thought I'd throw it in...
Hi Mark, David,
This is interesting. But even with 'unlock screen', wouldn't Rev be
subject to screen refresh cycles for displaying things? To me,
refreshing the screen on the very next cycle is like catching a bus -
you can catch the very next bus, but you have to wait until it arrives
before doing so. (sorry - simple analogies and metaphors are the only
ways I can understand some things!)
Seems to me there's a hardware-induced lag time here that can't be
eliminated or controlled from scripting. The best we can hope for is
accurately measuring the lag so we can compensate for it in scripting.
At least that's what I'm shooting for.
I would like to find a way to accurately pinpoint the appearance time
of objects without using an external.
I've experimented with this approach:
- position the mouse over the loc of a (still hidden) graphic
- show a solid-color (255,0,0) graphic
- put the milliseconds into x
- wait until the mouseColor = "255,0,0"
- put the milliseconds - x
If the mouse keeps moving while waiting for the object to appear, this
approach seems to work - at least the timings it yields are plausible,
in the 10 to 25 msec range. But the mouse has to be moving.
To determine what it was about mouse movement that made it
[apparently] work, I tried a couple of things:
- bombard the object with 'mouseMove' messages from
shortly before 'show' to some time after 'show'
- script some mouse movement throughout the 'show' period,
staying within 2 pixels of the loc of the object
Neither of these efforts yielded the same kind of timings I got when
manually moving the mouse. Instead I get 250 msecs or so.
Any other ideas?
Thanks -
Phil Davis
Best,
Mark
On 27 Apr 2007, at 13:10, David Glasgow wrote:
Thanks to all who previously chipped in on this topic. I have been
doing a bit of research, using the following script:
+++++++++++++++++++++
on mouseUp
-- scrollbars to fiddle with the various times
-- duration of the image of the person
get the thumbpos of scrollbar "milliseconds"
-- duration of the gap between picture and mask
put the thumbpos of scrollbar "gap" into tgap
-- this is the duration of the mask
put the thumbpos of scrollbar "show" into tshow
-- present a submarine style cross to focus attention
show group "targit"
wait 1000 milliseconds
hide group "targit"
put the milliseconds into tstart
show image "adf03"
wait it milliseconds
hide image "adf03"
put the milliseconds - tstart & return after field "actualtime"
wait tgap milliseconds
show grc "rectangle"
wait tshow milliseconds
hide grc "rectangle"
end mouseUp.
++++++++++++++++++++++
What happens is that a crosshair style target appears for 1 sec. Then
a picture of a person appears for 'it' milliseconds, then there is a
gap of tgap milliseconds, then a mask appears for tshow milliseconds.
The mask is a rect filled with a pattern. Its purpose is a technical
one, called backward masking (no, not like on heavy metal records).
If an image appears briefly followed by the mask, the amount of
conscious psychological processing permitted by the person viewing it
can be truncated. Images which would be recognisable at a given
display duration are rendered invisible but still processed
psychologically. Don't ask how, it just works. (If your really want
to know, take a look here --> http://www.ac-psych.org/?id=3 )
You can above see that field 'actualtime' accumulates the duration of
the display of the picture of the person (plus the time taken to do
the timing) over successive runs. With the duration of the person
image set at 30 ms, (gap = 40 ms and mask = 160 ms), I shouldn't be
able to see the image of the person, at least not conciously, but I can.
Now I expected to get variable effects in appearance, because I am
testing on a MacBook, so my guess is that the LCD just won't keep up
with these rapid display changes. What I was planning to do was shift
the test stack to a CRT box, and set the refresh rate to 100Hz (in
fact I think it goes to 138Hz). In the literature, I can see that
images can be displayed for a single cycle at 60Hz, and the effect can
work). What surprised me on the MacBook is the recorded variability
of the durations, irrespective of the fact that I can see the person
when I shouldn't be able to. The mean measured display time (set as
above) is 38 ms, min 32 and max 50, Standard Deviation = 4.46 (over 30
trials). I can slide the scrollbar to such a short duration when I
can't see the image of the person, but of course I can't know whether
this is because the backward masking is working, or because the image
really isn't appearing!
One of the things which occurred to me is that I could adapt the test
script above to do a kind of calibration routine, so that the
milliseconds is set to fall in the middle of the distribution of
actual durations, so that some will be a little shorter than 30ms,
and others a little more.
I would welcome any thoughts or comments on what I am doing, and
suggestions for doing it better.
Best Wishes,
David Glasgow
_______________________________________________
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
