Things I've learned building a modern TUI framework
&gt; The first trick is &quot;overwrite, don&#x27;t clear&quot;. If you clear the &quot;screen&quot; and then add new content, you risk seeing a blank or partially blank frame for a brief moment. It&#x27;s far better to overwrite the content in the terminal entirely so that there is no intermediate blank frame.<p>&gt; The second trick [...]<p>&gt; The third trick [...]<p>This is pretty hilarious to consider when coming from Win32API.<p>Its traditional to clears the window before showing anything on Win32. Clearing the window happens so fast that you shouldn&#x27;t see a flicker, even as the mouse moves over your window (each pixel your mouse cursor moves, Win32API will clear the window to its background, redraw the window (erasing the old mouse pointer), and draw the mouse pointer in the new location.<p>This &quot;TUI needs to be overwritten, not cleared&quot; idea seems quaint and slow. Win32API was drawRect(background color) for decades on ancient 386 machines and fast enough to deliver a good experience. Why is a 80 x 24 terminal window so much slower?<p>&gt; In Textual the layout process creates a &quot;render map&quot;. Basically a mapping of the Widget on to it&#x27;s location on the screen. In an earlier version, Textual would do a wasteful refresh of the entire screen if even a single widget changed position. I wanted to avoid that by comparing the before and after render map.<p>Win32API creates and maintains the &quot;invalidRect&quot;, the rectangle that needs to be re-rendered from scratch (ie: draw-calls called upon the hierarchy of &quot;windows&quot; from the background to foreground, in order , to make the overall window look unchanged).<p>Not only from mouse-cursor movements, but also as other windows &quot;move&quot; ontop of your window, or Clippy&#x27;s speech bubble disappears (if you remember that little UI from the 90s version of Microsoft Word).<p>And again, this needed to be done every time the mouse moved one pixel, to erase the old mouse cursor (aka: redraw the entire window from scratch &quot;over&quot; the old mouse cursor, making it look like you&#x27;ve erased it) and redraw the mouse cursor on top of the fresh coat of paint. It was an incredibly common operation even in 20MHz 80386 land from the early `90s.<p>There&#x27;s just no way a modern terminal is that slow, unless there&#x27;s a billion layers of vsync &#x2F; refreshes going on. There&#x27;s definitely something wrong going on IMO here.<p>&gt; Unicode art is good<p>This is true. Heck, ASCII art &#x2F; symbols are often good enough to do many, many things.<p>There&#x27;s something wrong with the terminal model at the fundamental level if you&#x27;re a couple of magnitudes slower than the 1980s. I can&#x27;t say I&#x27;m an expert on TUI (or guis for that matter), but... this whole blog post is kind of a horror story IMO.