gary@cirl.UUCP (Gary Girzon) (12/20/85)
The RAW: output device, the built-in general purpose ANSI-terminal
type window, seems to be a little slow. I have not formally benchmarked
the device speed, but it falls somewhere near 100 chars/sec. If you have
MicroEmacs running, the output is much slower that ED. I assume ED draws
to the screen directly. MicroEmacs opens a RAW: window for output.
Also, the Amigaterm program posted recently writes characters
directly to the window using graphics library calls. The output is
definitely faster and keeps up with 1200 baud. I have a similar
terminal program which redirects the output to a RAW: window, and it
runs much slower. The advantage of the RAW: is that it offers built
in ANSI sequences, like cursor motion, character styles, etc.
So does anyone have a handle on how to speedup the RAW: device?
Or will one have to rewrite it (so much for built in goodies) to
achieve faster output?
Gary
UUCP: ...{ihnp4,harvard}!think!cirl!gary bruceb@amiga.UUCP (Bruce Barrett) (12/24/85)
To Gary, and others-- >.....I assume ED draws to the screen directly. MicroEmacs opens a RAW: >window for output. ?? Draws to the screen directly?? There are several ways to get to the screen. I belive the least effecient of these is "printf" (because it goes through all the other layers too). >Also, the Amigaterm program posted recently writes characters >directly to the window using graphics library calls. Most effecient routines are ^^^^^^^^^^^^^^^^^^^^^^ > The advantage of the RAW: is that it offers built >in ANSI sequences, like cursor motion, character styles, etc. This advantage can also be achived by using the console device. Sooo... the overhead brakes down something like: Lowest: Graphics routines (no ESC sequences handled) console.device fh = Open (RAW:xx/yy/xxx/yyy/name); + Write (fh, buf, len); fd = fopen (... Highest: printf(..... Use whatever fits your needs best. Oh, for additional speed (at loss of colors) you might try: opening a custom screen 1 bit plane (2 colors) deep. I don't know but think this may save you 50% of the blit for your text. --BruceB
rico@oscvax.UUCP (Rico Mariani) (12/24/85)
In article <241@cirl.UUCP> gary@cirl.UUCP (Gary Girzon) writes: >The RAW: output device, the built-in general purpose ANSI-terminal >type window, seems to be a little slow. I have not formally benchmarked >the device speed, but it falls somewhere near 100 chars/sec. If you have >MicroEmacs running, the output is much slower that ED. I assume ED draws >to the screen directly. MicroEmacs opens a RAW: window for output. >Also, the Amigaterm program posted recently writes characters >directly to the window using graphics library calls. The output is >definitely faster and keeps up with 1200 baud. I have a similar >terminal program which redirects the output to a RAW: window, and it >runs much slower. The advantage of the RAW: is that it offers built >in ANSI sequences, like cursor motion, character styles, etc. > >So does anyone have a handle on how to speedup the RAW: device? >Or will one have to rewrite it (so much for built in goodies) to >achieve faster output? > Good day everyone! I am a brand new Amiga owner (i.e. I own a brand new Amiga :-) ) and I have a few comments re: raw: above... I downloaded uEmacs to my Amiga over the phone (same one I'm using now... thank God for 1200 baud modems...) and got it compiled and running with no trouble at all, thanks to decent code and an errata posting. I too found uEmacs *very* slow at redrawing the screen or any other major text operations (like inserting a character near the beginning of a line (reminds me of that 1200 baud modem I'm so fond of)). Well I refused to believe that I was going to have to write of 'raw:' as a peice of junk (you haven't let me down yet Amiga), so I tried this little experiment: type >raw:1/1/600/180/Foo BIGFILE lo and behold the output flew by my eyes at amazing speeds In an effort to see what type is doing differently we try: type <raw:1/1/100/100/Foo and as you type characters into the Foo window you will see exactly no output until all of a sudden like, type outputs a line. So that tells me that type buffers its output... Conclusion: There is a large overhead to pay with each call that is made to the raw: output driver. To avoid this overhead you should package the output into nice big chunks, as big as you can get them. uEmacs eventually outputs its characters with: Write( terminal, &c , 1 ) this is *slow*, with a little hacking here and there I changed it so that it would emit it's lines with only one call to Write. Emacs now reminds me of a 19200 baud terminal. Quite useable. I won't post the source unless I'm nagged but if you want to make the changes yourself they're not to hard, the pertinant files are display.c and termio.c. I added a function called ttputnchar which emits n chars to the terminal ( Write(terminal, string, n) ; terminal is a static in termio.c ) once this is done, snoop around display.c for likely single character outputs in loops to fix, there's lots. This fix should be a part of the next posting of microEmacs (are you listening O Great Source Keeper? ) Merry Christmas -Rico DISCLAIMERS: I don't know what I'm talking about. The Science Centre doesn't know what I'm talking about. You probably don't know what I'm talking about. So nobody can possibly be expected to be responsible. ...{allegra,linus,decvax,ihnp4,watmath}!utzoo!oscvax!rico P.S. Does anybody know how to send an EOF from the keyboard?? Somebody? Anybody? Whimper... :-(
louie@trantor.UMD.EDU (12/25/85)
From: Louis A. Mamakos <louie@trantor.UMD.EDU> You can improve the performence of the RAW: device by making larger requests (i.e. more than 1 character) to it. I did this to MicroEMACS, and noticed a very large improvement in performence. I've played around a bit with the AmgiaTERM program, and I believe that you could substitute the console.device handler to get the ANSI terminal emulation capabilites without significant degradation in performence. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
hamilton@uiucuxc.CSO.UIUC.EDU (12/26/85)
>I won't post the source unless I'm nagged but if you want to make the >changes yourself they're not to hard, the pertinant files are display.c >and termio.c. I added a function called ttputnchar which emits n chars >to the terminal ( Write(terminal, string, n) ; terminal is a static in >termio.c ) once this is done, snoop around display.c for likely >single character outputs in loops to fix, there's lots. hell, just cannibalize the VMS code in termio.c. wayne
mykes@3comvax.UUCP (Mike Schwartz) (12/27/85)
> From: Louis A. Mamakos <louie@trantor.UMD.EDU> > > You can improve the performence of the RAW: device by making larger requests > (i.e. more than 1 character) to it. I did this to MicroEMACS, and noticed a > very large improvement in performence. I've played around a bit with the > AmgiaTERM program, and I believe that you could substitute the console.device > handler to get the ANSI terminal emulation capabilites without significant > degradation in performence. > > Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU > University of Maryland, Computer Science Center - Systems Programming I will be posting the source to a program called dumbterm tomorrow. I will describe how it works here: The Amigaterm program posted here was a nice illustration of how nicely amiga programs can be written. However, it had a couple of bugs, and did not provide any ANSI capabilities at all. To modify the program to do the ANSI stuff would have taken a long time, and would have duplicated the work done by two of the Amiga device drivers - CON: and RAW:. CON: (console.device) is not desirable for a terminal program because it is a syncrhonous device. What I mean is that there is no way to test for ONE character ready at a time, and any read from it requires the user to hit return for A WHOLE LINE at a time. It does provide some additional editing features, like backspace and ctrl-x (line rubout), too. The RAW: device, on the other hand, does provide the ability to read and check for ready status one keystroke at a time. It provides the same ANSI capabilities as CON:, and sends ANSI sequences for the function keys and arrow keys. Openning either of these devices and doing asyncrhonous IO calls to them are possible, and is probably the BEST way to do IO to them. However, AmigaDos itself provides file IO calls that are real easy to use - Open, WaitForChar, Read, Write, and Close. DISCLAIMER: Someone at Amiga reading this is probably thinking "OFF WITH HIS HEAD!". WaitForChar is not a real good way to check for a keyboard key ready, BUT IT DOES WORK, and what do you want for free? Also, AmigaDos does not really provide a friendly way to get at an IDCMP for these devices. Anyhow, serial IO IS done via the asynchronous IO calls to the serial device, as is done in AmigaTerm, becuase AmigaDos does not provide WaitForChar capabilities for any device other than Raw: and Con: (I can't imagine why, though, as this would be a great feature. Actually, writes to the serial port and screen are done synchronously, because they require little time compared to the transmission time at any serial rate. It would be relatively simple to add xmodem (thanks to the Amigaterm source) and other types of communication features, but I will leave it up to you (readers, that is). What dumbterm is, is a small terminal program that works REAL NICE with UNIX over a modem (but that's all it does). It also illustrates all I discussed here. Until tonite, when I post the source... /mykes