about summary refs log tree commit diff stats
path: root/500fake-screen.mu
Commit message (Collapse)AuthorAgeFilesLines
* .Kartik K. Agaram2021-10-111-1/+3
|
* support combining characters in streams of textKartik K. Agaram2021-09-021-1/+22
| | | | Fake screens can't handle them yet.
* fix bad terminology: grapheme -> code pointKartik K. Agaram2021-08-291-44/+36
| | | | | | | | | | Unix text-mode terminals transparently support utf-8 these days, and so I treat utf-8 sequences (which I call graphemes in Mu) as fundamental. I then blindly carried over this state of affairs to bare-metal Mu, where it makes no sense. If you don't have a terminal handling font-rendering for you, fonts are most often indexed by code points and not utf-8 sequences.
* bugfix in commit 8e182e394Kartik K. Agaram2021-08-291-1/+3
| | | | | Any command in shell that rendered the screen resulted in an infinite loop. But it took me forever to even realize it was an infinite loop.
* width-aware drawing primitivesKartik K. Agaram2021-08-291-20/+96
| | | | No support yet for drawing wide graphemes.
* .Kartik K. Agaram2021-08-281-59/+44
|
* support unused screen-cells in fake screensKartik K. Agaram2021-08-281-0/+19
| | | | | | We'll need this when rendering 16-bit glyphs. They'll occupy two 8x16 display units on screen, but the grapheme is a single unit as far as fake screens are concerned.
* .Kartik K. Agaram2021-08-281-21/+21
| | | | Convert some old code to current idioms.
* .Kartik K. Agaram2021-06-151-1/+0
|
* flickerlessly render fake screens in environmentKartik K. Agaram2021-06-151-1/+45
| | | | | | | | Font rendering now happens off the real screen, which provides the effect of double-buffering. Apps can now also use convert-graphemes-to-pixels for more traditional double-buffering.
* .Kartik K. Agaram2021-06-121-29/+1
| | | | | Roll back to commit 70919b45f0. Recent commits add lots of extra function args for dubious benefit.
* snapshotKartik K. Agaram2021-06-121-1/+29
| | | | Looks like what's slowing down screen rendering is in fact _font_ rendering.
* make fake screens more realisticKartik K. Agaram2021-06-061-9/+33
| | | | The real screen silently clips coordinates out of bounds.
* shell: scrolling the traceKartik K. Agaram2021-05-291-1/+2
|
* start double-bufferingKartik K. Agaram2021-05-181-0/+39
| | | | | Amazing how much difference it makes even when the implementation is so naive and slow.
* .Kartik K. Agaram2021-04-211-0/+11
|
* reimplement pixel graphicsKartik K. Agaram2021-04-191-50/+101
| | | | | | | | | | | Before: we always drew pixels atop characters, and we only drew pixels that were explicitly requested. After: we always draw pixels atop characters, and we only draw pixels that don't have color 0. Both semantics should be identical as long as pixels are never drawn atop characters.
* .Kartik K. Agaram2021-04-191-33/+33
|
* add some checksKartik K. Agaram2021-04-191-2/+18
| | | | | | | Even if they duplicate lower-level ones, we have an opportunity for better error messages. Any time I see a hard-to-debug error message, I should be asking myself, "what higher-level primitive should catch and improve this error?"
* start cleaning up pixel graphicsKartik K. Agaram2021-04-191-1/+1
| | | | | | Filling pixels isn't a rare corner case. I'm going to switch to a dense rather than sparse representation for pixels, but callers will have to explicitly request the additional memory.
* Revert "allow drawing all pixels"Kartik K. Agaram2021-04-181-2/+3
| | | | It causes us to run out of memory during tests.
* allow drawing all pixelsKartik K. Agaram2021-04-171-3/+2
| | | | So far we aren't running out of memory. Might as well loosen our belts.
* shell: horline working nowKartik K. Agaram2021-04-151-1/+9
| | | | And we give a high-level error when the pixel buffer fills up.
* shell: don't lose pixel graphics when moving cursorKartik K. Agaram2021-04-141-0/+1
|
* shell: pixel graphicsKartik K. Agaram2021-04-131-0/+431