oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/04/89)
Kudos to Earle Horton for a fine posting on using asynchronous i/o. In that posting, he talks about the printer idle proc. Inside Macintosh leads one to believe that you can just disable the "page setup" and "print" menu items, and call your main event loop to let the user do arbitrary things while a document is printing. I've tried this, and taken it out again. At least with the imagewriter drivers of a year ago, the printer idle proc doesn't get called often enough (about once a second) to give the user interface enough time. The user interface from inside printing feels so sluggish that the idea wasn't worth it. It certainly is worthwhile to update the screen, and check the "Cancel" button on a "Printing in Progress" dialog. (Command-. isn't very friendly for a novice user.)
earleh@eleazar.dartmouth.edu (Earle R. Horton) (01/06/89)
In article <27335@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >... Inside Macintosh leads >one to believe that you can just disable the "page setup" and "print" menu >items, and call your main event loop to let the user do arbitrary things >while a document is printing. I've tried this, and taken it out again. At >least with the imagewriter drivers of a year ago, the printer idle proc >doesn't get called often enough (about once a second) to give the user >interface enough time. The user interface from inside printing feels so >sluggish. > I suppose I should have pointed out that exactly how much time you get back here is dependent on the printer driver, the Style options, and the Job options. It all depends on how much CPU time and how much I/O time is required by the chosen method. If you choose "Tall Adjusted" from the Style dialog and "Faster" from the Job dialog, then you get back enough time to allow the user to do plenty of things. This is true for the ImageWriter driver, anyway. Assuming that the user interface while running from a pIdleProc is too sluggish is not valid in all cases. There is also no reliable means of predicting how sluggish it will be with any given printing job, either, since that requires device-dependent information. The fact is that there do exist printer files which give back significant computation time to an application when using some printing styles/methods. If you allow for the possibility that one of these may be in use while you print, then you get a more user-friendly printing interface, at least some of the time, and it is worth it. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Graduate student.
alexis@ccnysci.UUCP (Alexis Rosen) (01/07/89)
I'd just like to point out that the big boys agree with David on this one. If you think way back to early 1984, you may recall that MicroSoft let the user regain control while the app was printing (this was in MS-Chart, and perhaps one of their other apps as well). Then when they finally released Chart, that feature vanished, never to be seen again. By the way, I don't mean to imply that MicroSoft made an intelligent decision, just that that's what they did :-) Alexis Rosen alexis@ccnysci.uucp
anson@spray.CalComp.COM (Ed Anson) (01/11/89)
In article <27335@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >... Inside Macintosh leads >one to believe that you can just disable the "page setup" and "print" menu >items, and call your main event loop to let the user do arbitrary things >while a document is printing. I would not be inclined to do any user interaction or drawing in this way. A printer driver can (and does) do strange things to the application's environment during a print job. Remember: Not everything that affects graphics is in the GrafPort. And what about memory allocation? The usual advice is to purge as much as possible from memory prior to the output phase of spooled printing. The driver wants that memory for itself. There may not be enough left for the application to do anything useful without impeding the print job. Then there's the application data structures. Do we really want the user to change them while we're trying to compose a printed page from them? OK, we might get away with it sometimes. I think the user is far better off if we just use a good print spooler. Let the application concentrate entirely on printing for the few seconds it needs to spool the output, and then return to interactive use. This way, there is less code complexity, and fewer opportunities for things to go very seriously wrong. DISCLAIMER: The opinions stated above are my own, and do not necessarily reflect the official policy of my employer. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM