bb@cypress.cis.ufl.edu (Brian Bartholomew) (12/02/90)
In article <1990Dec1.190910.19687@murdoch.acc.Virginia.EDU> pts@mendel.acc.Virginia.EDU (Paul T. Shannon) writes: > I think you missed the point. If you still disagree, I'd like to > hear why. Fair enough. > Nonetheless, it's my job to write software to run experiments in > psychophysics. This demands that stimuli, either auditory or visual, > be presented for precise and repeatable amounts of time. I was originally responding to your question as posed - "how do I take over the whole screen for my program". I saw a very good answer to that posted which stayed within the bounds of NeXTStep, and a very bad one that didn't; so I flamed the second one. Unfortunatly, I obviously didn't have the big picture. It is my new understanding that in order for your program to be useful, you must have accurate animation, perhaps timed as close as a millisecond. You already know that this is almost impossible without something like a DSP to generate precise timing, and still darned tough - > ($4,000 annual maintenance fee on Concurrent [Masscomp] equipment) It would be my contention, as an extremely lazy programmer who doesn't like writing real-time software, that you might want to consider a machine that was fast enough in general that you could use the window system in its full glory *and* still meet your timing requirements. With the amount of money that seems to have already been spent on real-time UNIX boxes, something extremely fast like an RS/6000 might not have a cost that is out of line. > I can't hope to do precise animation if I let the update program do a > disk sync (flushing dirty buffers to disk) every 30 seconds. But I > can do it if I can run as root, eliminate unnecessary daemons, suspend > update completely, maybe run in single user mode, and gain direct > access to display memory. You might be able to use more of the built-in NeXTStep software by making a distinction between "things that make timing unpredictable", like update, and "things that make drawing slower than direct memory access", like the window system and the appkit. You probably already know about page-swapping techniques where you have the window system prepare animation frames in full generality offline, then batten down your system and blit them onto the screen under tight control. > ("You need to learn the rules before you can break them.") Right. However, I suspect the "direct-access" poster did not know the rules he was breaking, nor the value of what he was giving up. I especially did not want the novice readers of the group to believe that this should be standard practice. Lastly, it personally irked me to see such "bad" technique flouted and used unless it was absolutely the only possible way to achieve the desired result. I still maintain that these techniques are unacceptable except for certain extremely special cases such as yours. (Note to application writers: yours is not a special case! This means you!) -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!mathlab.math.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu