unify blitters using dankblit algorithm

[dankamongmen]

During the course of sexblitter development, I worked out a general algorithm that takes as input

• Y*X cell geometry (i.e. 2x2 for quadblitter), and
• the properly-ordered set of 2^(Y*X) EGCs

and blits its little heart out. We ought be able to collapse the 909 lines in blit.c to maybe 200 or fewer.

[julianhess]

Would it pick the optimal character from the entire set ∪{8x1,2x2,3x2} (obviously, {1,2,4}x1 are made entirely redundant by 8x1, and there would also be a bit of redundancy between individual characters in the remaining 3 subsets), or would it still be restricted to a single subset within the union?

[dankamongmen]

What is implied here is you would still use the current API (i.e. specify some NCBLIT_*, including possibly NCBLIT_DEFAULT), but rather than each calling a completely different function, each will map to a one-line inline wrapping a common function, and supplying geometry+glyphset to that common function.

To answer your question (I think), NCBLIT_2x2 includes all the NCBLIT_2x1 glyphs; NCBLIT_2x1 includes the single NCBLIT_1x1 glyph; NCBLIT_3x2 includes three glyphs from NCBLIT_2x2 (the LEFT HALF and RIGHT HALF, and the space from NCBLIT_1x1). NCBLIT_4x2 is just Braille, because Braille together with sections doesn't make sense IMHO. Likewise Sixel/Pixel.

As for, say, adding UPPER HALF and LOWER HALF to sexblitter, it's a nice thought -- it suggests you could get still "more" vertical resolution -- but it doesn't actually work out, i think, because you've got to map the same number of pixels to each row...hrmm maybe it could be made to. I'm unsure. Will think.

but this bug is all about just internal reorganization, ideally with no user-visible side effects.

[julianhess]

As for, say, adding UPPER HALF and LOWER HALF to sexblitter, it's a nice thought -- it suggests you could get still "more" vertical resolution

Yup, that's more or less what I was getting at. Also adding the horizontal eighth blocks (U+258{9,B,D,F}) to gain horizontal resolution, and possibly the quadrant blocks if those happen to render a set of pixels with higher fidelity than a sextant block (e.g., if the set of pixels comprising the cell is close to perfectly quartered or horizontally bisected).

Basically, a blitter that chooses the optimal glyph from the combination of all unique glyphs from eightstep, quadblitter, sexblitter, and the horizontal eighth blocks.

[dankamongmen]

As for, say, adding UPPER HALF and LOWER HALF to sexblitter, it's a nice thought -- it suggests you could get still "more" vertical resolution

Yup, that's more or less what I was getting at. Also adding the horizontal eighth blocks (U+258{9,B,D,F}) to gain horizontal resolution, and possibly the quadrant blocks if those happen to render a set of pixels with higher fidelity than a sextant block (e.g., if the set of pixels comprising the cell is close to perfectly bisected/quartered).

So before we blit, especially with the aspectratio-nonmaintaining quad/sex blitter, we regularly run a resize via the multimedia engine.

E.g. let's blit a 4096x4096 image to a 64x256 terminal.

• 64x256 using sexblitter allows 192x512 pixels
• 64x256 using quadblitter allows 128x512 pixels
• 64x256 using halfblocks allows 128x256 pixels (with a 2:1 cell aspect ratio, this maintains the original aspect ratio)

so i run the blitting analysis on this scaled image, scaled to the optimal geometry for the blitter. three pixel rows for sexblitter correspond to one cell row. there's no way that 3 pixel rows can be perfectly bisected (i mean, maybe if you have { A, (A + B)/2 , B} you're best off going to { (2A + B) / 2, (A + 2B) / 2 } or something rather than sexblitter's choice of { (2A + B) / 2 on a 2/3 upper block and B on a on a lower 1/3 block }). so it seems we'd have to scale to some least common multiple LCM (6 for quadblitter + sexblitter), which blows up analysis time, and also means we're effectively doing scaling that could have been left to the (presumably much more competent) media layer.

i haven't sat down and proven any of this out, though. so feel free to hit back with real analysis (pun not intended)!

[dankamongmen]

we're using the inverse of dankblit to implement the modern, panblitter ncplane_as_rgba() in #1490. once we've proven that out, this ought follow naturally.

[dankamongmen]

We've completed the inverse panblitter ncplane_as_rgba(), so this ought follow pretty easily.