# WaitSecs fills screen with zeros in 8-bit mode, OS X **URL:** \ **Category:** Uncategorized\ **Created:** [August 23, 2002, 2:33pm UTC](https://psychtoolbox.discourse.group/t/waitsecs-fills-screen-with-zeros-in-8-bit-mode-os-x/1360 "2002-08-23T14:33:47Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [August 23, 2002, 2:33pm UTC](https://psychtoolbox.discourse.group/t/waitsecs-fills-screen-with-zeros-in-8-bit-mode-os-x/1360/1 "2002-08-23T14:33:47Z")
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 \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ---
**Author:** ![denispelli](https://avatars.discourse-cdn.com/v4/letter/d/cdc98d/32.png) [@denispelli](https://psychtoolbox.discourse.group/u/denispelli)\ **Post date:** [August 23, 2002, 3:11pm UTC](https://psychtoolbox.discourse.group/t/waitsecs-fills-screen-with-zeros-in-8-bit-mode-os-x/1360/2 "2002-08-23T15:11:04Z")
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](http://psychtoolbox.org) > \>POST a message to: [psychtoolbox@yahoogroups.com](mailto:psychtoolbox@yahoogroups.com) > \>UNSUBSCRIBE by sending a blank message to: > \>[psychtoolbox-unsubscribe@yahoogroups.com](mailto:psychtoolbox-unsubscribe@yahoogroups.com) > \> > \>Your use of Yahoo! Groups is subject to [http://docs.yahoo.com/info/terms/](http://docs.yahoo.com/info/terms/) ---
**Author:** ![Allen\_Ingling](https://avatars.discourse-cdn.com/v4/letter/a/a183cd/32.png) [@Allen\_Ingling](https://psychtoolbox.discourse.group/u/Allen_Ingling)\ **Post date:** [August 23, 2002, 4:26pm UTC](https://psychtoolbox.discourse.group/t/waitsecs-fills-screen-with-zeros-in-8-bit-mode-os-x/1360/3 "2002-08-23T16:26:21Z")
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