[1] Except for the early oscilloscope style vector displays maybe.
EDIT: If you mean they were not copied in a frame buffer first, you are right. I should not have written 'blitting'.
I believe on some systems there were some tricks that allowed some bitmap display by redefining glyphs. One example off the top of my head is The 8-Bit Guy's Planet X2, which can use text mode but with glyphs redefined to use for icons, units, terrain, UI, etc.
No. Stop believing everything ChatGPT told you on this topic and DYOR. That's some bad hallucinations.
Might be fun though to check with ChatGPT on how to use a screw driver in this context. :-)
My original point that putting a fixed number of small and fixed rectangles on a screen is more efficient than line drawing still stands though.
Without dedicated sprite hardware it's not more efficient to read a byte from one place and write a byte to another than to write background bytes and write line colour bytes. DMA controllers on µCs won't save you: a character is usually something like 8x8 or 8x16 and displays are rarely more than 8 bit, so we're talking about DMA transfers of just 8 bytes each, and the overhead of setting them up more than offsets any efficiencies gained.
An 8x12 cell, for example, is 96 pixels to be transferred in 12 rows of 8 pixels. That's 96 reads, 96 writes, and (assuming an unrolled inner loop) 12 branches, to copy as a sprite. Or, it's 96 writes and 12 branches to clear, and (horizontal line) another 8 writes to draw, no branches.
When your graphics become too complex for simple drawing routines to handle them, they're probably also too complex for simple character ROMs, too.
There's quite a few ways to do this, you can do a DMA transfer per horizontal/vertical screen line (not enough memory for a fullscreen buffer, but usually enough memory for 2 fullscreen lines), with an interrupt which fills in the next line to be transfered, etc.
> displays are rarely more than 8 bit
Backing memory in these color TFT SPI displays is often 18bits per pixel, often transfered as RGB565 (2bytes) per pixel.
For SSD1306 its 1bit per pixel, and even the weakest MCUs usually have enough memory for a second buffer.
All this is completely ass-backwards thinking though. The crucial question is - does the end-user/customer want to see smooth lines or prefers "hacker-man" TUI aesthetics.
I'd say you generally speaking users want normal smooth lines graph instead of hackerman aesthetics.
So preferring implementation simplicity (TUI) might be another case where substandard programmers prioritize their convenience over the end-user needs/preferences.