pixel graphics march on

[nick black]

Pixel graphics have proven just as difficult to integrate as
expected, especially when one considers both Sixel and the Kitty
protocol. But we're gonna do 'em both, and we're gonna do 'em
right. 2.3.0 can wait until it's a gem.

https://www.youtube.com/watch?v=SLya_k_lQL0

First on the agenda is improving Sixel performance and quality.
We're currently using a lame popularity algorithm. I'm going to
move to either median cut, octrees, or Kohonen neural nets. I'm
thinking the last is the best, as the former two require
enumerating our colors before calculating them, with resultant
memory penalty and two compulsory passes. I want to get Sixel
rendering down to sub 20ms, so we can run at least 50fps of it
without complex multithreading. Is it possible? We'll see.

libsixel uses histogram+median cut. It's way better than we are,
currently, but I feel confident that I can improve upon it.

https://www.youtube.com/watch?v=Kyq4J9dkHHs

Next come moving and deleting pixel graphics. I was stuck on
this, until the answer appeared to me in a dream last evening. I
woke up and wrote down my thoughts this morning:
https://github.com/dankamongmen/notcurses/issues/1388. I think
this will work. Everything keys off proper invalidation of
underlying cells -- not one cell too many, nor too few.

https://www.youtube.com/watch?v=jBfygUiS50g

Once that's proven out, the final step is integrating pixels
with colocated updated cells. The strategy here is similarly
outlined in bug #1388. If we pull it off, we'll be in a class
alone, high atop the mountain, and have essentially done
everything one can do with a terminal.

https://www.youtube.com/watch?v=cPRKsKwEdUQ

Excelsior!

--rigorously, nick

--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.