Feature Request: Add retro Apple II cursor style

[PhMajerus]

Description of the new feature/enhancement

Considering Terminal has a Retro terminal effects option, I suspect some people like some nostalgia in their command line experience. The Cursor shape option has a Vintage style that seems to be based on the original IBM PC and MS-DOS. Most older personal computers didn't use that style, the Filled box was the most common, but there is one outsider that is still missing in Terminal.

The Apple II used the checkerboard stored in the 0x7F position (delete) of its character set as its cursor. It is an uncommon checkerboard symbol that has the same size as a mathematical symbol (such as +).

It would be nice to have that as an option, for old times' sake.

It wouldn't turn into a huge set of weird legacy cursors to support, because as far as I can tell, only the Tandy/RadioShack is another uncommon system, with something that looks like a top rectangle on the cell below. But I don't know that system enough to be sure. All the other classic systems I tested use a full block: Commodore PET, C64 and later, Amstrad CPC, MSX, MSX2, MSX2+.

Proposed technical implementation details (optional)

I guess Terminal uses characters as cursors, so we really just need that character and an option in the settings to select it.

It just so happens that Cascadia 2404.23 contains the character we need, it is U+2427 Symbol for delete square checker board form (symbol for delete in the Apple II character set) .

Another solution could be to allow any character to be used with a "custom" cursor that, when selected, also provides a field to specify the character to be used. This would be more flexible but less easy as users would need to know which character to use instead of discovering it in the list of cursors.

Can you consider adding that as a cursor option for us old-timers?

[lhecker]

Our most commonly used cursor "color" is one that inverses the underlying color to always keep it visible:

However, there's a problem: If the underlying color is very close to gray (or some equivalent) then the inverse will also be gray which causes the cursor to be invisible. To solve that issue, we compute color distances when drawing the cursor and nudge the cursor and inverted text colors to be further apart. Finally, we also need to stretch the cursor when hovering over a wide glyph and it's unclear how that would look like with this grid shape.

While the 5x5 grid glyph can technically be implemented just like the empty box cursor as a set of rectangles, this one would result in not just 4 but 25 rectangles. Every single one of those would consist of 2 individual triangles during rendering. That's certainly anything but optimal.

The proper solution here would be to draw the glyph into our glyph cache and use it as a pixel-by-pixel lookup texture to invert every underlying pixel where the lookup texture is lit/white. This would need to be implemented in the pixel shader. But there's multiple problems with that:

• Requires us to port the color distance algorithm to HLSL.
• Requires us to invert the text at the time it is being blended into the swap chain. This is because text rendering is gamma corrected based on the text color and this information is lost once the blending finished. Inverting the color retroactively leads to either too thin or too fat looking stems in the glyphs.
• Right now, we upload the pixel shader constant buffer as an immutable buffer, which is quite efficient. This change would require us to turn that into a dynamic buffer because the constant buffer would need to store the changing location of the cursor in the viewport. Graphics drivers may handle dynamic constant buffers by allocating large ring buffers so that they can be efficiently pipelined. We'll have to test all of our relevant hardware on how they react to such a change. After all, we're trying to optimize the renderer for power draw and memory usage, while graphics drivers are always trying to optimize us as if we were a video game. This conflict of interests continues to be an issue for us.

I think rendering cursor in the pixel shader is the right way to do it, no matter what. The importance of this feature VS the time required for testing it is the real issue unfortunately. 😟

[PhMajerus]

@lhecker Hey, I know that segmented 0! 😉

Thanks for all the details. And yeah, I was hoping it could just be an extra label and character in a list of cursors. I didn't think about the way you invert the character under the cursor. On the Apple II, the cursor is not xor-blitted with the character at that position, it simply toggles between the character and the cursor. So I was thinking about that behavior which is basically just changing the character at the cursor position on the blink interval. The work involved isn't worth it for the nostalgia thrill, and apps can still achieve the same result by swapping the character explicitely.