bb@loggerhead.cis.ufl.edu (Brian Bartholomew) (12/01/90)
In article <1990Nov28.234910.28347@murdoch.acc.Virginia.EDU> pts@mendel.acc.Virginia.EDU (Paul T. Shannon) writes: > For those curious, or skeptical, I want to do this so that I can use > the entire display, with as little interference and overhead as > possible, to present full-screen visual stimuli for experiments in > perceptual psychology. ----- In article <11920@milton.u.washington.edu> wiml@milton.u.washington.edu (William Lewis) writes: [Discusses a sicko PC-style direct-screen-memory access method that throws away memory protection, eliminates restoration of revealed window areas, breaks multiple-program access to the screen, throws away portability to other NeXT machine and OS versions, eliminates the printer, and generally requires a much more skilled programmer to write a much more picky and detailed program that is much less reliable.] Writing trash like this may be acceptable for PC's running Windows or Mac's running finder. However, garbage like this is not acceptable for modern UNIX workstations, *especially* ones shipped with the premier window-system-development tool on the market. I have noticed that the Lotus people broke the Sun version of 123 the same way, by explicitly going out of their way to write directly into screen memory. As a consequence, when this program hangs as it does occassionally, your window manager (SunView) is shot dead in the water. Will people never learn? > Sigh, the price of portability is control. Incorrect. With some trivial Postscript, you may write to any pixel in any window you open. However, you do not give up any features of DPS or NeXTStep. > Flames about portability and philosophy to /dev/vid0. I did this, but it wrote trash all over my screen, and then crashed my window manager and hung my machine. Too bad I was not protected by all the memory protection and multitasking cooperation carefully designed into UNIX and the window manager in the first place. Of course, you can expect any program that uses this method to be equally reliable. ----- Please see article <11902@milton.u.washington.edu> by wjs@milton.u.washington.edu (William Jon Shipley), earlier in this group, for a proper method to accomplish this goal. -- "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
pts@mendel.acc.Virginia.EDU (Paul T. Shannon) (12/02/90)
In article <25678@uflorida.cis.ufl.EDU> bb@loggerhead.cis.ufl.edu (Brian Bartholomew) writes: > >In article <1990Nov28.234910.28347@murdoch.acc.Virginia.EDU> >pts@mendel.acc.Virginia.EDU (Paul T. Shannon) writes: > >> For those curious, or skeptical, I want to do this so that I can use >> the entire display, with as little interference and overhead as >> possible, to present full-screen visual stimuli for experiments in >> perceptual psychology. > >----- > >In article <11920@milton.u.washington.edu> >wiml@milton.u.washington.edu (William Lewis) writes: > >[Discusses a sicko PC-style direct-screen-memory access method that >throws away memory protection, eliminates restoration of revealed >window areas, breaks multiple-program access to the screen, throws >away portability to other NeXT machine and OS versions, eliminates the >printer, and generally requires a much more skilled programmer to >write a much more picky and detailed program that is much less >reliable.] > >Writing trash like this may be acceptable for PC's running Windows or >Mac's running finder. However, garbage like this is not acceptable >for modern UNIX workstations, *especially* ones shipped with the >premier window-system-development tool on the market. As the originator of this topic, perhaps it's my place to reply. I agree with the sentiments of the poster, though I propose that they don't address the issue, *my* issue. I respect standards, and I spend a lot of my programming time writing careful, portable code. I admire the people who created NeXTstep, and their work, I *use* it, and I ususally obey the rules religiously. 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. For a number of years I've used Masscomp's Real-Time Unix, which runs in tandem with a dedicated, single-tasking graphics processor, and allows for such precise control. Masscomp (now Concurrent) equipment however, is very expensive to buy and maintain. The annual maintenance fee on our 68020, 4mb, 80mb disk system is more than the cost of a single NextStation. To add a disk, or NFS, will cost us a lot of money. Then along comes the NeXT: a great system at a great price. It looks like I can use it as it was intended, to write well-behaved programs, and to use a burgeoning amount of 3rd party software. And it looks like I can adapt it so that I can get my experiments written and running. Maybe this will persuade you that there are times when it's not always stupid to break the rules. (I'm reminded of the jazz musician who said: 'You spend 10 years learning your instrument, then 10 years learning the music, then you forget all that sh.t'). 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 probably see this as "trash" and "a sicko PC-style" , but I see it as compromises that may help me to get my work done. I'm not writing commercial software. I think you missed the point. If you still disagree, I'd like to hear why. - Paul Shannon pts@virginia.edu
glang@Autodesk.COM (Gary Lang) (12/03/90)
>memory. As a consequence, when this program hangs as it does >occassionally, your window manager (SunView) is shot dead in the >water. Will people never learn? Well you have a good point. But there are other things to consider. The main mode of operation for a good piece of software is not an error condition but running under normal circumstances. Suppose that not writing to memory meant unacceptable performance. Would you be willing to trade a clean death of an application for those few times it crashes for blazing performance when it isn't crashing? Part of the PC success story comes from the high degree of interaction afforded by performance tricks like writing to video memory directly. The perception of slowness has hindered large-scale accceptance of GUI platforms for quite some time. The systems now have pretty good performance even with large OO toolkits like NeXTStep, but it didn't used to bethis way. Running OpenLook on my 16MB Sparc1+, I can safely say that the performance is unacceptable to an audience consisting of would-be former PC users. That is to say, everything feels like a Mac 512K did 5 years ago. If Lotus has gotten around this by mucking with the system and made their application useful except in error conditions, I take my hat off to them. - g
bb@swamp.cis.ufl.edu (Brian Bartholomew) (12/05/90)
In article <1023@autodesk.COM> glang@Autodesk.COM (Gary Lang) writes: > Well you have a good point. But there are other things to consider. > The main mode of operation for a good piece of software is not an error > condition but running under normal circumstances. Suppose that not > writing to memory meant unacceptable performance. Would you be willing > to trade a clean death of an application for those few times it crashes > for blazing performance when it isn't crashing? Considering all the various software I have used, on different platforms at different times, I must conclude "no". Almost every time I have seen an application writer attempt to skirt the edges of this trade off, they have ended up creating an application that is unusable because it is unreliable. Most of the time, when I have seen such an application, I have suspected that the programming approach was not one of careful weighing of alternatives, but merely unwillingness to exert the effort to properly error-trap the code. Besides, in the land of Murphy's Law, there is no set of "normal circumstances". > Part of the PC success story comes from the high degree of interaction > afforded by performance tricks like writing to video memory directly. > The perception of slowness has hindered large-scale accceptance of GUI > platforms for quite some time. The systems now have pretty good > performance even with large OO toolkits like NeXTStep, but it didn't > used to bethis way. You probably had a point back before 1985-ish (note the fast GUI Commodore and Atari products created then) when the "PC"'s were toys, but not any longer. Now, a workstation-class machine holds the title of "fastest" for perhaps 6 months, then is replaced by a machine twice as fast. Let's all stop coding applications as if our app was the only code executing on the machine. If Microsoft had written a decent ANSI.SYS (ANSI standard terminal escape screen device driver) for DOS that wasn't done half-ass'ed and slowly, apps could have skipped writing directly to screen memory in the first place. This would let products like a multi-tasking simulator like AST's DesqView be implemented in a reasonable fashion. One of the major problems with previous PC products was that the system implementers created guidelines for applications and wrote toolboxes, but then proceeded to break their own rules for thier own apps. Both UNIX and NeXT product implementations follow their own rules, much to everyone's benefit. When was the last time you saw a C programmer replace stdio.h with their own package? > Running OpenLook on my 16MB Sparc1+, I can safely say that the > performance is unacceptable to an audience consisting of would-be > former PC users. That is to say, everything feels like a Mac 512K did > 5 years ago. If Lotus has gotten around this by mucking with the system > and made their application useful except in error conditions, I take my > hat off to them. Well, I completely disagree with your speed assessment. I have noticed that most "real" systems seem to fall between an apparent I/O rate of 4800 baud, to 19.2 Kbaud. Once the screen update gets faster, users feel they can afford to install another layer of software and functionality. ----- Your comments seem to indicate that you disagree with the "overhead" of an Operating System. The purpose of an Operating System is to enable shared use of resources, insulate you from other users, and contain the damage from programs with flaws. A user-level application writing directly to screen memory prevents all of these from taking place. If you want a fast PC, get a 486. I'll take a NeXT. I'm tired of flaming DOS, and I expect the net is tired of listening. Enough. -- "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
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (12/05/90)
[stuff about direct access to framebuffer memory] To address the original question, I'd use DKIOCGADDR. > Writing trash like this may be acceptable for PC's running Windows or > Mac's running finder. However, garbage like this is not acceptable > for modern UNIX workstations, *especially* ones shipped with the > premier window-system-development tool on the market. Speak for yourself. I consider it barely usable. > I have noticed that the Lotus people broke the Sun version of 123 the > same way, by explicitly going out of their way to write directly into > screen memory. As a consequence, when this program hangs as it does > occassionally, your window manager (SunView) is shot dead in the > water. Will people never learn? I suspect it is actually something else. I have often seen things draw on the raw framebuffer while SunView is running, and not once have I even heard a report of this hanging SunView - until now. >> Sigh, the price of portability is control. > Incorrect. With some trivial Postscript, you may write to any pixel > in any window you open. How does one arrange for this to happen automatically when some area of memory is poked? I'm not about to try to rewrite every framebuffer access in ddx/cfb to generate PostScript instead. And what's more, I shudder to think how much performance penalty would be involved in changing a three-instruction sequence to modify the framebuffer into code to generate the relevant PostScript and send it to the window server. I would be amazed by less than three orders of magnitude slowdown - which is, of course, completely unacceptable. The thing is already slow enough to verge on unusable. (In my opinion. Others more tolerant than I think it eminently usable.) >> Flames about portability and philosophy to /dev/vid0. > I did this, but it wrote trash all over my screen, and then crashed > my window manager and hung my machine. Odd. When my code clashes with the window server writing to the framebuffer, I just get corrupted screens. It's never crashed anything. (Said code has problems, but they're due to my playing fast and loose with DPS, not due to my drawing on the framebuffer behind the window server's back.) Yes, such techniques are dangerous; they require care. They decrease portability (which is not always a problem). But there are times when they are *the* way to address some need. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
glang@Autodesk.COM (Gary Lang) (12/06/90)
>I have seen an application writer attempt to skirt the edges of this >trade off, they have ended up creating an application that is unusable >because it is unreliable. Examples...? You're saying that 1-2-3 is "unusable"? Please, I think I'm being misunderstood here; I really meant that it's OK to do it in the PC world and yields real benefits. As I recall (probably diumly) this thread started because someone wanted to write a screensave without using the appkit. The NeXT is a perfectly good DPS system and it's perfectly fine to write an applcation that addresses the entire window rectangle through DPS - this is hardly bare metal work here. >but merely unwillingness to exert the effort to properly error-trap >the code. I thought we were discussing going around a system's protection mechanisms for performance, not exception handling. This is apple pie - everybody believes in proper exception handling (except..oh never mind). >When was the last time you saw a C programmer replace stdio.h with >their own package? The last time I saw a C programmer do that was about >Well, I completely disagree with your speed assessment. it's your right, but I find it unusable, so your disagreement doesn't increase the utility of it for me...it's just too slow. >Your comments seem to indicate that you disagree with the "overhead" >of an Operating System. The purpose of an Operating System is to... No of course not. Again I was referring to the PC world, not the windowing environment world. You're reading too much into what I said; I totally agree with you. While I am saying that developers like Lotus, Ashton-Tate et al who've been very successful at writing apps that break a few rules had good reason to do so, I am not saying that this is the case on a platform like the NeXT (I never intend to do it in my apps), and I'm not sure why I or anybody on the net needs a lecture on what Operating Systems are used for in this context. > If you want a fast PC, get a 486. I'll take a NeXT. I disagree. I think that the NeXT *is* a fast PC. Not to mention the best one, or the blackest one or the best of breed, etc. that's why I bought one and write software for it. All of this is my opinion (actually there is some fact here but...) and your mileage may vary.
rca@cs.brown.edu (Ronald C.F. Antony) (12/07/90)
In article <25742@uflorida.cis.ufl.EDU> bb@swamp.cis.ufl.edu (Brian Bartholomew) writes: >the first place. This would let products like a multi-tasking >simulator like AST's DesqView be implemented in a reasonable fashion. Well it is actually not by AST but by Quarterdeck, Inc. They even have a software patent on it (probably to scare off Mircosoft...) ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet