High speed redraw for graphical word processor

[flashjazzcat]

I've been tinkering with the screen redraw in The Last Word with a view to planning a future version which supports proportional fonts and variable text sizes. It occured to me that the only way to further optimize the speed of the screen redraw was to actually abandon refreshing the screen if the user is still typing (only updating the current line).

 

Video

 

The method needs some refinement but I think it could be the way forward when a full screen refresh takes more than a couple of seconds (this will certainly be the case when rendering proportional fonts). At the moment, the programming is simple: the refresh routine just quits as soon as a key is pressed (after it's printed the current line).

 

If there's any interest I'll try and build this into LW 3.1 as it stands. I've been trying it out and it's bloody fast. Quite a bit of work to do before it's bulletproof, though.

Edited November 10, 2009 by flashjazzcat

[Fres]

I, for one, am very impressed. Nice work (as usual).

[LoTonah]

Wow, that's looking pretty sweet! Too bad this wasn't 25 years ago, I'm sure it'd be the top-selling word processor

[ZylonBane]

Why is it taking so long to update the screen? If memory serves, ICE-T rendered 80-column text much faster than that.

[Laemeur]

I actually just started wrestling with this exact same problem a few nights ago as my first proper Atari assembly coding project. Here is a disk image with a very, very crude proportional font demo. Binary load TEST.65O from DOS, then run at address $3F33.

 

When you type forward, only the last character is blitted, but when you backspace, the whole screen is redrawn. Once you get a few lines down the screen, the redraw gets agonizingly slow.

[UNIXcoffee928]

Wow! That is really impressive!

 

I hadn't checked out your word processor, until now. From the looks of that video, you most certainly would have had the top word processor for the 8-bit Atari, back in the day.

 

One thing that I noticed while watching the video was CTRL-C to cut & CTRL-P to paste. This is foreign to modern users who are expecting CTRL-X & CTRL-V. What might be an excellent plan for a future version could be to supply the current set as a default CTRL mapping, but also allow the user to build a key-mapping from scratch, or to select from sets of popular old ones (AtariWriter, Wordstar, Word Perfect). This could appeal to a wide variety of users from all different generations.

 

Excellent work!

[JamesD]

Looks impressive. Pretty fast screen updates and it looks like it should keep up with your typing.

 

If you want something to shoot for, take a look at Max-10 for the Tandy CoCo 3. Its almost identical to Mac Write.

WYSISYG, dropdown menus, click buttons for settings (single/double space), integrated spelling checker, graphics import (even Mac pictures), etc...

Arguably the best word processor for any 8 bit and it came out in the 80s.

[flashjazzcat]

I actually just started wrestling with this exact same problem a few nights ago as my first proper Atari assembly coding project. Here is a disk image with a very, very crude proportional font demo. Binary load TEST.65O from DOS, then run at address $3F33.

 

When you type forward, only the last character is blitted, but when you backspace, the whole screen is redrawn. Once you get a few lines down the screen, the redraw gets agonizingly slow.

Looking good so far. The problems really come when you implement word wrap, etc. The way The Last Word is implemented (as of version 3.1), there are three distinct levels of optimisation:

 

1. At the bitmapping level, a character is only mapped to the screen if the relevant character isn't already there. This saves about 80% of bit mapping during everyday editing operations. This optimisation is implemented inside the put character routine so isn't simply confined to the editor's screen refresh.

2. Scrolling is done with a dynamic display list rather than block moves. This interacts quite neatly with (1) because of a list of pointers to the character maps for each line of the screen which are rotated up or down along with the LMS pointers in the DL.

3. A list of line lengths and line addresses (in the text buffer) is maintained and following an initial "full" redraw, the refresh routine checks these tables and skips anything which hasn't changed. At the minimum, only the current line is updated everytime a key is pressed. This is why there's a slowdown if a line wraps at the top of a long paragraph: all the text below reshuffles itself, triggering redraws for every line.

 

Current experiments have me totally convinced that incomplete screen redraws will be essential in a WYSIWYG word processor on the 8 bit. There are few drawbacks, since you only have to let up typing for a couple of seconds and the screen will properly update while the program is idle. I think it's worth putting into LW (3.11?) as it stands, because of the speed boost. I may actually junk (3) above and save cycles with some in-line code when implementing the interruptable screen refresh, since the complications of using this along with a line table which may or may not get a chance to update between keystrokes are immense.

 

Wow! That is really impressive!

 

I hadn't checked out your word processor, until now. From the looks of that video, you most certainly would have had the top word processor for the 8-bit Atari, back in the day.

 

One thing that I noticed while watching the video was CTRL-C to cut & CTRL-P to paste. This is foreign to modern users who are expecting CTRL-X & CTRL-V. What might be an excellent plan for a future version could be to supply the current set as a default CTRL mapping, but also allow the user to build a key-mapping from scratch, or to select from sets of popular old ones (AtariWriter, Wordstar, Word Perfect). This could appeal to a wide variety of users from all different generations.

 

Excellent work!

Thanks! If you read the chapter on macros in the manual, you'll see everything you want to do with the keyboard layout is already possible. Just define macros to map the keyboard the way you want it (making sure you map the commands whose keystrokes you've "robbed" onto different ones), and you're set. For example:

 

<Ctrl+V><Inv Equals><Ctrl+P>

 

Will put paste onto <Ctrl+V>. Save the file as LW.MAC and it will work that way by defualt. Don't forget to map another key onto <Ctrl+V>, or you'll lose Print Preview. <Ctrl+P><Inverse Equals><Ctrl+V> will put preview on <Ctrl+P>.

 

I'll try to include some keymapping macros on the next distribution disk.

 

Looks impressive. Pretty fast screen updates and it looks like it should keep up with your typing.

 

If you want something to shoot for, take a look at Max-10 for the Tandy CoCo 3. Its almost identical to Mac Write.

WYSISYG, dropdown menus, click buttons for settings (single/double space), integrated spelling checker, graphics import (even Mac pictures), etc...

Arguably the best word processor for any 8 bit and it came out in the 80s.

Hard to find screens of Max-10, but I found a couple and it looks good. Anywhere you can recommend with in-depth information?

Edited November 11, 2009 by flashjazzcat

[flashjazzcat]

Here's a slightly improved version:

 

Second version

 

Sadly the removal of the previous optimisation technique slows it down in other ways. There's bound to be a compromise to be found. In any case, this way the redraw will never interrupt your typing.

[JamesD]

Looks impressive. Pretty fast screen updates and it looks like it should keep up with your typing.

 

If you want something to shoot for, take a look at Max-10 for the Tandy CoCo 3. Its almost identical to Mac Write.

WYSISYG, dropdown menus, click buttons for settings (single/double space), integrated spelling checker, graphics import (even Mac pictures), etc...

Arguably the best word processor for any 8 bit and it came out in the 80s.

Hard to find screens of Max-10, but I found a couple and it looks good. Anywhere you can recommend with in-depth information?

Max-10 used a proprietary hi-res mouse interface. If you didn't buy it, you wouldn't be able to run it.

That's probably why there are no videos or photos of it in action.

I have the original disks plus a lot of font and border disks for it that I won in an auction. Sadly, no interface was included.

I posted a request on CoCo3.com for someone to make a video so we'll see.

 

You can find manuals here:

http://www.nationsdial.com/adit/page8/page8.html

[+Stephen]

Looking good as usual.

 

Sorry if this is a dumb question - could you turn off the word wrap while editing to save processing time then when done typing "re-wrap" it?

 

Stephen Anderson

[Laemeur]

It's funny to have to really think about this stuff when text-editing on modern hardware seems so ubiquitous and instantaneous. It's a very fun programming challenge. Thanks a lot for your insight.

 

Looking good so far. The problems really come when you implement word wrap, etc. The way The Last Word is implemented (as of version 3.1), there are three distinct levels of optimisation:

 

1. At the bitmapping level, a character is only mapped to the screen if the relevant character isn't already there. This saves about 80% of bit mapping during everyday editing operations. This optimisation is implemented inside the put character routine so isn't simply confined to the editor's screen refresh.

2. Scrolling is done with a dynamic display list rather than block moves. This interacts quite neatly with (1) because of a list of pointers to the character maps for each line of the screen which are rotated up or down along with the LMS pointers in the DL.

3. A list of line lengths and line addresses (in the text buffer) is maintained and following an initial "full" redraw, the refresh routine checks these tables and skips anything which hasn't changed. At the minimum, only the current line is updated everytime a key is pressed. This is why there's a slowdown if a line wraps at the top of a long paragraph: all the text below reshuffles itself, triggering redraws for every line.

 

Current experiments have me totally convinced that incomplete screen redraws will be essential in a WYSIWYG word processor on the 8 bit. There are few drawbacks, since you only have to let up typing for a couple of seconds and the screen will properly update while the program is idle. I think it's worth putting into LW (3.11?) as it stands, because of the speed boost. I may actually junk (3) above and save cycles with some in-line code when implementing the interruptable screen refresh, since the complications of using this along with a line table which may or may not get a chance to update between keystrokes are immense.

[flashjazzcat]

Sorry if this is a dumb question - could you turn off the word wrap while editing to save processing time then when done typing "re-wrap" it?

You can turn word-wrap off with CTRL+W at any time (the document may take a second to reformat as will any other document you flip to while it adopts the new setting), but the processing for word-wrap is so incidental it probably won't make much difference. Actually, word-wrap often speeds things up because without it, all the text up to a return gets pushed along and redrawn after each keystroke. So it's probably a lot faster with word-wrap on.

 

It's funny to have to really think about this stuff when text-editing on modern hardware seems so ubiquitous and instantaneous. It's a very fun programming challenge. Thanks a lot for your insight.

Yes - VERY good fun indeed. These are the same challanges which faced professional programmers working on the early GUIs and such like, when processing power was at a premium. Saving cycles by interrupting the screen redraw is hopefully going to allow for some fairly complex on-screen formatting. somewhere down the line. Incidentally, I finally figured out how to combine the line table and interrupted redraws: Once the current and "previous" lines are drawn, force a redraw of all the subsequent lines lower down on the screen. This means if you're editing at the top of the screen, the current and previous lines will be drawn straight away and keystrokes can then safely interrupt lines below without fear of screen corruption, because the next time the program's idle it will fully redraw all the lines down to the end of the screen. Conversely, if the current and previous lines are near the foot of the screen, although keystrokes won't be acted upon until these two lines are drawn, the line table optimisation will have skipped over the uppermost lines, and any text to be pushed along will be off the bottom of the screen anyway.

Edited November 12, 2009 by flashjazzcat

[flashjazzcat]

Ah... luxury. Here's a beta of LW 3.11 with the new fast refresh running on a VBXE2 equipped 320XE on the 22" LG TFT:

 

LW 3.11 Beta with VBXE2

 

 

 

 

[Heaven/TQA]

Ah... luxury. Here's a beta of LW 3.11 with the new fast refresh running on a VBXE2 equipped 320XE on the 22" LG TFT:

 

LW 3.11 Beta with VBXE2

 

cool stuff! looks so clear...

[candle]

Jon, when we could count on TLW with true VBXE support? first thing i did was disabling 80 columns mode because i couldn't stand lettering

its not hard to setup 80 column text mode, nor to use blitter for the screen refresh - should be as easy as replacing one call (for rewriting words) with BCB

[flashjazzcat]

Jon, when we could count on TLW with true VBXE support? first thing i did was disabling 80 columns mode because i couldn't stand lettering

its not hard to setup 80 column text mode, nor to use blitter for the screen refresh - should be as easy as replacing one call (for rewriting words) with BCB

As soon as I get time to work on it, and it promises to be good. However, 80 columns working on a stock machine was always my main priority, and I think it looks good as it is - especially with VBXE's clear picture. Using VBXE's 80 column text mode will be less challenging and more limited as regards the number of users, but it will certainly be a fast and capable word processor, and far easier on the eyes.

Edited November 13, 2009 by flashjazzcat