FD22 wrote:God no - having the renderer dictate system character I/O rate would be ... insane.
I'm quite sure, that under 'normal' circumstances the character rate won't ever exceed something like 1000 characters per second. If you take the LIST command as example, I took one arbitrary example program, where a LIST needed 5.5 seconds, and resulted in 3580 bytes when redirected to a file: ~650 bytes/second.
If we take that further, 650 characters/second correspond to 13 characters per frame (PAL, 50 Hz), so for single character output, a full-line renderer for 40 columns would only run at 33% efficiency.
Direct output doubles the CPU load for each character, as it presumably has to write the same bitmap bytes twice for the resulting double char in each 8x8 pixel cell, but besides that it only needs to write to the parts of the bitmap that really must be updated.
if, in the interim, they've actually caused the entire screen to scroll one or more lines, the renderer doesn't care because it locates whatever dirty row markers are set and refreshes accordingly. And even if that means all 24 dirty row markers are set, it's still only a 5th of a second to refresh the whole screen, and the refresh looks smooth and responsive.
So that again looks like you let your program perform the scroll by the renderer at last. If you only can scroll 5 times a second, that won't look smooth - it will look very jerky, with lines jumping around haplessly depending in which state of the scroll they have been 'caught' by the renderer.
As you might know, I already had my hands into 40-column display routines. There's
MG Browse, with some routines that descended from my paint program MINIPAINT. It only uses a renderer for complete lines, but then the exposed API is especially tuned for fast text display with scrolling in a bitmap. It is possible to modify the source text lines on-the-fly and re-paint them, but I just didn't include single character rendering because I was lazy.
Instead, I put the time into the formatting routine, which takes a file and puts it into RAM with word wrapping and TABs, so a BASIC program has no big hassle scrolling several KB of text around.
If you take a look into the source of MG Browse, you'll also see the nibbles of the character definitions doubled in each byte. And the inner render loop for each double char is also quite similar - but then, the need for maximum speed nearly automatically leads to that solution.
For
MG Text Edit I actually derived a single character output routine from the line renderer. It did this mainly, because the text display renders on a MINIGRAFIK bitmap, and normally there is neither an off-screen ASCII/PETSCII buffer available, nor was it intended to introduce one. It just 'paints' the glyphs as typed in. Speed is of no big importance here, as the limiting element is the user before the computer, and there's no scrolling.
That all being said, I'm looking forward how FAST-40 will look in practice.