WaitSecs fills screen with zeros in 8-bit mode, OS X

I sent this message yesterday, but it hasn't shown up, so I'm sending it
again.

I have encountered a problem using WaitSecs in 8-bit mode under OS X
Classic. Here is a simple program and its output to demonstrate the
problem. WaitSecs appears to be filling the screen with zeros, for some
reason. Can anyone confirm this behavior on their OS X machine? I don't
recall getting this error just a few days ago (though it is possible), and
the only change I've made to the system was to install the latest security
update from Apple.

Interestingly, if I run this program in 32-bit mode (by commenting out the
second line of the program), I see that the FillRect values are not
registered until a WaitBlanking command is issued (image4 ~= image5).

keith

-----

The program:

res = SCREEN(0, 'Resolution');
res.pixelSize = 8;
w = SCREEN(0, 'OpenWindow', 128, [], res);
image1 = SCREEN(w, 'GetImage', [0 0 3 3])
SCREEN(w,'WaitBlanking')
image2 = SCREEN(w, 'GetImage', [0 0 3 3])
waitsecs(1)
image3 = SCREEN(w, 'GetImage', [0 0 3 3])
SCREEN(w,'FillRect',255);
image4 = SCREEN(w, 'GetImage', [0 0 3 3])
SCREEN(w,'WaitBlanking')
image5 = SCREEN(w, 'GetImage', [0 0 3 3])
SCREEN('CloseAll')

-----

The output:

image1 =

128 128 128
128 128 128
128 128 128


image2 =

128 128 128
128 128 128
128 128 128


image3 =

0 0 0
0 0 0
0 0 0


image4 =

255 255 255
255 255 255
255 255 255


image5 =

255 255 255
255 255 255
255 255 255

-----

My screentest report:

*** keith's Classic Mac OS Compatibility/866, Mac OS 9.2 *****************
G4, 867 MHz, memory bus 133 MHz, 97.259 Mflop/s
Psychtoolbox 2.52, 12 August 2002, Matlab 5.2.1.1421
*** Screen 0 *************************************************************
"" (.Display_Video_Apple_BB200 version 1)
8 bit dacs. 1280x1024 60 Hz. (60,65,67,70,72,75,76,80,85,100,120 Hz avail)
Prefs: SetClutDriverWaitsForBlanking 0.
- - - - - - - - - - - - - - - - - - - - - - - - -
pixel size 8 16 32 bits
pages 1 1 1
CopyWindow (ie CopyBits) 177 189 192 MB/s
SetClut suppresses ints. for 0.0 0.1 0.0 frames
LoadClut vs. GetClut? ( 8 bits) == == ==
LoadClut vs. GetClut? (10 bits) no no no
- - - - - - - - - - - - - - - - - - - - - - - - -
SetClut waits for blanking (i.e. ~60 Hz) if parameters have these values:
prioritySequence clutEntries pixelSize
63 Hz: 0/0 all 8
93 Hz: 0/0 all 16
SetClut doesn't wait for blanking if parameters have these values:
prioritySequence clutEntries pixelSize
138 Hz: 0/0 one 8
211 Hz: 7/0 one 8
412 Hz: 7/7 one 8
381 Hz: 7/0 all 8
388 Hz: 7/7 all 8
126 Hz: 0/0 one 16
246 Hz: 7/0 one 16
442 Hz: 7/7 one 16
179 Hz: 7/0 all 16
439 Hz: 7/7 all 16
154 Hz: 0/0 one 32
439 Hz: 7/0 one 32
440 Hz: 7/7 one 32
150 Hz: 0/0 all 32
412 Hz: 7/0 all 32
414 Hz: 7/7 all 32
- - - - - - - - - - - - - - - - - - - - - - - - -
SetGamma waits for blanking (i.e. ~60 Hz) if parameters have these values:

49 Hz:
The following parameters don't affect whether SetGamma waits for blanking:
prioritySequence clutEntries pixelSize
**************************************************************************
dear keith

amazing. the program runs fine under mac os 9.2.2 on my powerbook.

THEORY 1:

WaitSecs doesn't do much, so i'm guessing that it's not what it does,
but the fact that the mex file has to be loaded from disk to memory
that somehow has the side effect of wiping your screen.

if that's right, i would predict that a second call to waitsecs would
have no effect. or that preceding your program by a call to waitsecs
would fix it. and the calling "clear waitsecs" would undo the fix.

you might try substituting waitticks(60) instead. or use tic and toc,
which are built-in.

currently i'm at a loss to provide a theory as to what is wrong that
could account for this result.

THEORY 2:

the result you describe for 32-bit pixels, where the image arrives
later than you expect is something i detected and wrote to apple
about during the beta testing of mac os x. CopyBits has always been
synchronous, but under mac os x Classic, beta, it was sometimes
asynchronous, returning immediately and doing the copy later. I asked
how I could tell when the copy was done and never got a reply.

THEORY 3:

hmm. i wonder if asynchronous image update is what's going on in both
anomalies.

in your first case you're changing the resolution. when QuickDraw
changes resolution it also clears the screen. then Screen.mex fills
the rect with the 128 you specified. I wonder if the clear by
QuickDraw might be delayed and occur much after the loading of the
128. To you it seems to be "caused" by the WaitSecs, but in fact it
was going to happen anyway.

what do you think?

it is starting to seem that apple really cut corners in implementing
mac os x classic. the copybits problem we could overcome by always
using our own code: CopyBitsQuickly. The problems you're experiencing
here would need to be better understood if we're going to work around
them.

best

denis

>I sent this message yesterday, but it hasn't shown up, so I'm sending it
>again.
>
>I have encountered a problem using WaitSecs in 8-bit mode under OS X
>Classic. Here is a simple program and its output to demonstrate the
>problem. WaitSecs appears to be filling the screen with zeros, for some
>reason. Can anyone confirm this behavior on their OS X machine? I don't
>recall getting this error just a few days ago (though it is possible), and
>the only change I've made to the system was to install the latest security
>update from Apple.
>
>Interestingly, if I run this program in 32-bit mode (by commenting out the
>second line of the program), I see that the FillRect values are not
>registered until a WaitBlanking command is issued (image4 ~= image5).
>
>keith
>
>-----
>
>The program:
>
>res = SCREEN(0, 'Resolution');
>res.pixelSize = 8;
>w = SCREEN(0, 'OpenWindow', 128, [], res);
>image1 = SCREEN(w, 'GetImage', [0 0 3 3])
>SCREEN(w,'WaitBlanking')
>image2 = SCREEN(w, 'GetImage', [0 0 3 3])
>waitsecs(1)
>image3 = SCREEN(w, 'GetImage', [0 0 3 3])
>SCREEN(w,'FillRect',255);
>image4 = SCREEN(w, 'GetImage', [0 0 3 3])
>SCREEN(w,'WaitBlanking')
>image5 = SCREEN(w, 'GetImage', [0 0 3 3])
>SCREEN('CloseAll')
>
>-----
>
>The output:
>
>image1 =
>
> 128 128 128
> 128 128 128
> 128 128 128
>
>
>image2 =
>
> 128 128 128
> 128 128 128
> 128 128 128
>
>
>image3 =
>
> 0 0 0
> 0 0 0
> 0 0 0
>
>
>image4 =
>
> 255 255 255
> 255 255 255
> 255 255 255
>
>
>image5 =
>
> 255 255 255
> 255 255 255
> 255 255 255
>
>-----
>
>My screentest report:
>
>*** keith's Classic Mac OS Compatibility/866, Mac OS 9.2 *****************
>G4, 867 MHz, memory bus 133 MHz, 97.259 Mflop/s
>Psychtoolbox 2.52, 12 August 2002, Matlab 5.2.1.1421
>*** Screen 0 *************************************************************
>"" (.Display_Video_Apple_BB200 version 1)
>8 bit dacs. 1280x1024 60 Hz. (60,65,67,70,72,75,76,80,85,100,120 Hz avail)
>Prefs: SetClutDriverWaitsForBlanking 0.
> - - - - - - - - - - - - - - - - - - - - - - - - -
>pixel size 8 16 32 bits
>pages 1 1 1
>CopyWindow (ie CopyBits) 177 189 192 MB/s
>SetClut suppresses ints. for 0.0 0.1 0.0 frames
>LoadClut vs. GetClut? ( 8 bits) == == ==
>LoadClut vs. GetClut? (10 bits) no no no
> - - - - - - - - - - - - - - - - - - - - - - - - -
>SetClut waits for blanking (i.e. ~60 Hz) if parameters have these values:
> prioritySequence clutEntries pixelSize
> 63 Hz: 0/0 all 8
> 93 Hz: 0/0 all 16
>SetClut doesn't wait for blanking if parameters have these values:
> prioritySequence clutEntries pixelSize
> 138 Hz: 0/0 one 8
> 211 Hz: 7/0 one 8
> 412 Hz: 7/7 one 8
> 381 Hz: 7/0 all 8
> 388 Hz: 7/7 all 8
> 126 Hz: 0/0 one 16
> 246 Hz: 7/0 one 16
> 442 Hz: 7/7 one 16
> 179 Hz: 7/0 all 16
> 439 Hz: 7/7 all 16
> 154 Hz: 0/0 one 32
> 439 Hz: 7/0 one 32
> 440 Hz: 7/7 one 32
> 150 Hz: 0/0 all 32
> 412 Hz: 7/0 all 32
> 414 Hz: 7/7 all 32
> - - - - - - - - - - - - - - - - - - - - - - - - -
>SetGamma waits for blanking (i.e. ~60 Hz) if parameters have these values:
>
> 49 Hz:
>The following parameters don't affect whether SetGamma waits for blanking:
> prioritySequence clutEntries pixelSize
>**************************************************************************
>
>
>http://psychtoolbox.org
>POST a message to: psychtoolbox@yahoogroups.com
>UNSUBSCRIBE by sending a blank message to:
>psychtoolbox-unsubscribe@yahoogroups.com
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Well, I didn't figure out what the problem was, but when I installed the
new version of the OS X (10.2), the 8-bit mode problem went away, though
the 32-bit problem still remains. Weird.

> you might try substituting waitticks(60) instead. or use tic and toc,
> which are built-in.

Yes, this is what I ended up doing, and it worked fine, so it must've
been something to do with loading the mex file.

> hmm. i wonder if asynchronous image update is what's going on in both
> anomalies.
>
> in your first case you're changing the resolution. when QuickDraw
> changes resolution it also clears the screen. then Screen.mex fills
> the rect with the 128 you specified. I wonder if the clear by
> QuickDraw might be delayed and occur much after the loading of the
> 128. To you it seems to be "caused" by the WaitSecs, but in fact it
> was going to happen anyway.
>
> what do you think?

No, because when I changed WaitSecs to WaitTicks in the program I was
writing, the problem went away, so it was something to do with WaitSecs.

keith