srpenndo@uokmax.UUCP (Sean Richard Penndorf) (01/14/89)
I am writing a terminal program in LSP, and in my development have found that the DrawChar routine bogs down when you are connected at speeds greater than 1200baud. My ultimate goal is to be able to write to the screen at 2400baud. I have tried saving the font being used in a BitMap, then stamping it to the screen with CopyBits. I have also tried using DrawText, and the lower level routine StdText (?). So far, everything I have tried bogs down at 2400baud. Does anyone out there in NetLand have any clues to what I can try? Any comments at all will be greatly appreciated. Thanks in advance. Sean ---- -- Sean 'Longstride' Penndorf !texsun!uokmax!srpenndo . . .----------- GEnie: S.PENNDORF | | `---. srpenndo@uokmax.UUCP `--'LTIMATUM----'OFTWARE
grg@berlin.acss.umn.edu (George Gonzalez) (01/15/89)
Here's how to speed up your serial I/O to screen. I wish Red Ryder and Microphone were listening. (1) Don't use drawchar. There's too much overhead in drawing 1 char at a time.Try gathering 5-20 chars at a time and then drawing them all at once with DrawText or DrawString. This should help a lot. You'll need to special case the processing of control characters and escape sequences though. You'll also need a timeout to flush the last 5-20 characters. A bit messy but this is the only way you can go above 1200 baud on a plain Mac. (2) You then may find the bottleneck is in scrolling the screen. You can speed this up by scrolling up several lines at a time. This is somewhat ugly but at 9600 baud the eye can barely tell if you're scrolling 1 line or 3 lines at a time.
jmunkki@kampi.hut.fi (Juri Munkki) (01/15/89)
In article <2220@uokmax.UUCP> srpenndo@uokmax.UUCP (Sean Richard Penndorf) writes: >I am writing a terminal program in LSP, and in my development have found >that the DrawChar routine bogs down when you are connected at speeds >greater than 1200baud. My ultimate goal is to be able to write to the >screen at 2400baud. > >I have tried saving the font being used in a BitMap, then stamping it to >the screen with CopyBits. I have also tried using DrawText, and the lower >level routine StdText (?). So far, everything I have tried bogs down >at 2400baud. I am currently writing a terminal program and it can currently do about 95% of what MacTerminal does (including the ability to scroll back and copy stuff). The program easily supports 19200 baud on a Mac II, but I haven't tried it on a Plus or SE yet. I think you are experiencing a very commong beginner's problem. You are probably handling the characters one at a time. You get your character, look at it (to see if it's part of an escape sequence) and then draw it on the screen. This is not the efficient way to do it. I think you can get very close to 2400 baud with this technique, so you might be doing something else wrong too. (You might be drawing & erasing the cursor every time you draw a character.) I did some research before starting to write my terminal program. I tried drawing a string by drawing one character at a time and drawing it with a single call to drawstring or drawtext. In my tests, drawing the string was about six times faster than drawing a single character. When you have characters in the incoming buffer, do this: 1) Read all the characters with FSRead. 2) Hide the cursor. (Not the arrow, the block/underline in the terminal) 3) Remember the first character you are processing. 4) Process the characters looking for characters that QD can't handle. 5) If you find you have to move to another place on the screen, (you might be processing a return or a linefeed) draw the characters you have already handled with one call to DrawText. remember the next character you will be processing. else just advance to the next character. 6) When you have looked at all the characters, call drawtext for the remaining text. 7) Display the cursor at the new position. When receiving characters at a slow rate this routine will move the cursor for every character and draw the characters individually. At higher speeds the buffer tends to contain more characters and you end up drawing a whole line of characters with a single call to drawtext. I hope this helps. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
borcelf@jacobs.CS.ORST.EDU (Fernando Borcel) (01/16/89)
I remember writing a small term program. What I did was something like check
the driver buffer as many times as possible for input, and then use
TEInsert(), which is really fast. So i suggest you don't draw the text on the
screen, but use the standard TextEdit routines.
Tell me how it worked out!!!
-Fernando
___ __ |{tektronix,hp-pcd}!orstcs!
/ _ _ _ _ _ _/ _ /_/ _ _ _ _ / | jacobs.cs.orst.edu!borcelf
/- /_// // / _// // // / / )/ // // /_// |
_/ /_ / / //_// //_//_/ /__//_// /_ /_ /_ |borcelf@jacobs.cs.orst.edu d_volaric@vaxa.uwa.oz (01/17/89)
In article <2220@uokmax.UUCP>, srpenndo@uokmax.UUCP (Sean Richard Penndorf) writes: > > I am writing a terminal program in LSP, and in my development have found > that the DrawChar routine bogs down when you are connected at speeds > greater than 1200baud. My ultimate goal is to be able to write to the > screen at 2400baud. > > I have tried saving the font being used in a BitMap, then stamping it to > the screen with CopyBits. I have also tried using DrawText, and the lower > level routine StdText (?). So far, everything I have tried bogs down > at 2400baud. > > Does anyone out there in NetLand have any clues to what I can try? Any > comments at all will be greatly appreciated. Thanks in advance. > > Sean I don't know if you are doing so already, but I would buffer the text coming from the serial port and then use DrawText to draw a bunch of characters at the same time. I doubt whether DrawText of say, 10 characters is slower that 10 characters at 2400 baud. I would check the buffer every few ticks (60ths of a second) and draw it to the screen if there is anything there. I think "every few ticks" should be less than the time it takes for a person to type a character (10 ticks?) so that characters apear when the user types them. If you are into high-adventure you could use a VBL task. ( If DrawText is too slow, write your local congressman and/or Apple Systems Programmer :-) ) I hope this is some help. Darko "Yes, it is my real name" Volaric Disclaimer: These opinions are my own. I am only freeloading off the uni.
jcl@hpausla.HP.COM (Jeff Laing) (01/19/89)
George Gonzalez (grg@berlin.acss.umn.edu) writes in comp.sys.mac.programmer: > Here's how to speed up your serial I/O to screen. I wish Red Ryder and > Microphone were listening. Me too. > (2) You then may find the bottleneck is in scrolling the screen. You can > speed this up by scrolling up several lines at a time. This is somewhat ugly > but at 9600 baud the eye can barely tell if you're scrolling 1 or 3 lines > at a time. I found it was quite fast enough. However, you don't maintain an 80 x 24 char array of your screen image, but 24, 80 character buffers and a 24 buffer pointer array. When you scroll, use ScrollRect for the onscreen stuff and just roll the 24 pointers around; if your update processing indirects through the pointer array, it works fine. Oh, it also means you don't have lots of hidden 'multiply by 80's in your generated machine code, either.
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (01/20/89)
In reference to all the discussion about fast screen updates... Is there something equivalent to UNIX 'curses' where some "god" keeps a representation of what the screen 'should' look like at any time and then figures out the optimum way to actually change the physical screen? I guess this might be difficult for proportionally spaced fonts & such. Matt Kennel mbkennel@phoenix.princeton.edu
dean@mars.Berkeley.EDU (R. Drew Dean) (01/23/89)
In article <568029@vaxa.uwa.oz> d_volaric@vaxa.uwa.oz writes: >I don't know if you are doing so already, but I would buffer the text coming >from the serial port and then use DrawText to draw a bunch of characters >at the same time. I doubt whether DrawText of say, 10 characters is slower >that 10 characters at 2400 baud. I would check the buffer every few ticks ... >Darko "Yes, it is my real name" Volaric There's one problem with this approach: it's ugly. (As first pointed out to me by a friend, when I suggested the same thing :-)) If you want to see what it looks like, check out Miniterm (I have version 2.9.1) at 2400 baud. You'll see it jerk. Then look at VersaTerm. It's smooth, just like a real VT-100 is. I realize that it's probably not necessary to draw each character one at a time as they come in, but DrawText needs to be called with a small (ie. 2 or 3) number of characters each time, if you want the text to flow smoothly. Note that the MicroPhone II I saw (it wasn't 3.0, so things may be better now), drew text a _line_ at a time at 2400 baud. Personally, I didn't like the effect. Drew Dean Internet: dean@xcssun.berkeley.edu UUCP: ...!ucbvax!xcssun!dean FROM Disclaimers IMPORT StandardDisclaimer;
jmunkki@kampi.hut.fi (Juri Munkki) (01/24/89)
In article <9000@pasteur.Berkeley.EDU> dean@xcssun.Berkeley.EDU (R. Drew Dean) writes: >In article <568029@vaxa.uwa.oz> d_volaric@vaxa.uwa.oz writes: >>I don't know if you are doing so already, but I would buffer the text coming >>from the serial port and then use DrawText to draw a bunch of characters >>at the same time. I doubt whether DrawText of say, 10 characters is slower >>that 10 characters at 2400 baud. I would check the buffer every few ticks > >There's one problem with this approach: it's ugly. (As first pointed out >to me by a friend, when I suggested the same thing :-)) If you want to >see what it looks like, check out Miniterm (I have version 2.9.1) at 2400 >baud. You'll see it jerk. Then look at VersaTerm. It's smooth, just like >a real VT-100 is. I realize that it's probably not necessary to draw each >character one at a time as they come in, but DrawText needs to be called >with a small (ie. 2 or 3) number of characters each time, if you want the >text to flow smoothly. Hmmm... The problem isn't that the programs draw several characters at a time, but that they wait between the calls. My program looks very smooth and it usually draws about 80 chars at a time when used at 9600 or 19200. Look at the serial buffer, read all the characters that are already there and blast them to the screen. My program has two serial buffers. One for the drivers (normally about 8KB) and the other for FSRead (about 80 bytes). VersaTerm seems to draw the same way my program does. _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~