29

As far as I can remember the inverted (aka "XOR") style of mouse cursor has been around as long as there have been mice. I mean something like this:

enter image description here (source)

where the cursor shape is formed by dynamically inverting the colors of the individual underlying pixels. I'm pretty sure I saw this on Macs in the 80s and early versions of Windows.

I don't recall the exact methodology of forming the inverted image but I think it was based on an XOR bit manipulation.

Personally this is not my favorite style of cursor graphics, but tastes vary & I'm sure many people must like it. However given that there are also more standard solid black or white cursors this must have taken someone a bit of additional work to implement. And on top of that it seemed to become universal to have this style of cursor. That makes me wonder if there was some reason for it other than individual preferences?

Googling around this topic I gather there was even once some controversy over patents on this idea - more 'evidence' that there was a really good reason for it to exist?

8
  • 26
    that way, the cursor has a high contrast regardless of the color of whatever's behind it obviously.
    – OmarL
    Mar 30 at 15:53
  • 2
    @OmarL that's certainly true, but I guess I lumped that into the "aesthetics" though that may not be totally correct. My own experience has been that contrast issues are so rare that I've never needed this style, but this could be subjective or context-dependent. Mar 30 at 15:55
  • 34
    @OmalL On the original black-and-white Macintoshes, you often had surfaces (desktop background, etc.) made up of a single-pixel checkboard pattern, a halftone that passed for 50% gray. XOR cursors were actually very hard to see on those. Same thing for an actual gray surface (128,128,128) whose bitwise inverse is (127,127,127).
    – Nimloth
    Mar 30 at 17:17
  • 3
    @StayOnTarget Well, keep in mind, not everyone's eyes are the same. The whole thing is much like driving with headlights on during daytime to increase visibility. Many argue that they already see the car - which is of course true ... except, it's false, as it's about noticing it faster and more reliable. An inverted cursor brings exactly that.
    – Raffzahn
    Mar 31 at 1:41
  • @Nimloth I remember mid-grey giving me huge trouble implementing inversion in something years ago (probably greyscale, possibly colour). The workaround took more code than the general case. Inversion with a border helped but then you can't do the XOR(XOR(pixel)) approach to remove the cursor.
    – Chris H
    Mar 31 at 10:25
3

The technique predated the modern combination of mice and graphical displays. Text terminals needed to show the cursor simultaneously with the character being highlighted by, or adjacent to, the cursor. Several very simple techniques for that have been employed, and inverted characters, also known as XOR, ended up as the most conspicuous and rather common choice.

Bitmap graphics displays arrived to offer more flexibility, and their cursors were free to employ shapes in addition to a position; by that time, the use of reverse characters to indicate a cursor position on the screen was no less familiar to the general population than a thin solid horizontal or vertical line used for the same purpose. Those solid cursors usually had to be blinking in order to remain noticeable. And blinking cursors only work well if the remaining screen content remains very static.

The U.S. Patent US3609749A from 1969 (where the cursor generally wasn't mouse controlled and was limited to a rectangle spanning exactly one character on the screen) says:

A common problem when using such [earlier brightening or underlining] cursors is that when the display consists of large numbers of closely spaced, relatively small characters, it may be very difficult for the operator to distinguish the marked character location from the remaining character locations without excessive concentration and mental fatigue.

Later patents such as US5471570A use formulations such as "...so that the sprite is always distinctively visible irrespective of the underlying displayed data"

67

XORing a cursor into a frame buffer (which is what you seem to be calling "inverted cursor") is actually simpler than ORing it in there: when the cursor has to be removed again (to move to another position) you simply draw it a second time, with the same pixels, and it will vanish, courtesy of the XOR logic.

If you have ORed the cursor into the buffer (which results in a "solid" cursor), you need to remember what was originally there to be able to restore the original contents under the pointer.

XOR screen operations work best on monochrome screens or screens with a very limited color depth: On modern high-colour screens, XOR operations can produce pretty unexpected colours, you also can't be sure the cursor will have enough contrast to the background.

5
  • 1
    Light grey can be a problem even on low-colour screens: try finding a crosshair cursor on light grey (#808080), particularly when it's dithered!
    – ErikF
    Mar 30 at 18:08
  • 1
    I've wondered why there weren't systems using modular addition of 0x80 instead of XOR with 0xFF. That would avoid the problem with cursor being invisible on gray background due to 0x80 becoming 0x7F, while still being a reversible operation.
    – jpa
    Mar 31 at 5:50
  • 10
    XOR 80h does the same as modular addition of 80h, so speed of XOR / ADD is a red herring. But you're both assuming that the colour is represented as a 24-bit value so that each byte can be XORed with 80h. On early Mac or Windows systems, you might have a mono or planar framebuffer (8 pixels / byte), or 1 byte per pixel representing an index into a palette. XORing these values with 80h wouldn't work. When GEM sets up a palettized display, it orders the colours so that XORing a colour with 0FFh will give the inverse of that colour; I expect other systems do the same.
    – john_e
    Mar 31 at 9:23
  • 10
    The speed of the actual blit op is relatively irrelevant for choosing the logical operation used to blit the pointer. What is much more relevant, is, whether you need to move the orininal frame buffer contents under the pointer you're drawing to a safe place and back - or not. Because that is what affects performance.
    – tofro
    Mar 31 at 11:44
  • You might want to incorporate some of that last comment into the answer. The answer sort of implies but doesn't directly state that alternative drawing methods were not only harder to implement but would not have performed adequately. Apr 1 at 15:37
31

On Windows (1.x), at least, it's no more work to have this style of cursor than the normal sort. A Windows cursor is formed of two bitmaps: A mask that blanks out the shape of the cursor, and a pattern that is then drawn in the same place using the XOR operation. There are thus four possible combinations for any pixel:

Mask bit Pattern bit Resulting pixel
0 0 Black
0 1 White
1 0 Unchanged
1 1 Inverted

The ability to have inverting cursors thus emerges from the logic for the three other pixel types. The only coding necessary within Windows is to use XOR rather than OR to paint the cursor shape, which occupies no more code space.

On systems earlier than Windows or the Mac, where memory was restricted, it was a common technique for cursors to be drawn only with XOR (rather than the two-stage mask and bitmap system used by Windows), because this meant the operations to draw and remove them were identical – painting the cursor a second time would revert the screen to how it was before, and so the pixels overwritten by the cursor did not need to be saved in a buffer to be restored later.

5
  • 3
    Aha, so the XOR style was actually the original type? Or at least an early form... that certainly makes sense! Mar 30 at 15:56
  • 1
    On terminals, a full-height cursor is done by swapping the foreground and background colors. Is that related? Mar 31 at 7:37
  • 1
    @JohnDvorak: It depends on the implementation. If the screen appears to the computer as a sequence of characters and attributes (eg: IBM MDA, IBM 3270 PCDA), there may be a bit in the attribute to swap foreground and background, or it may be necessary to calculate a 'reverse video' attribute. If the characters are drawn as bitmaps into a framebuffer (eg: Amstrad PCW) then inverting a character-sized rectangle with XOR is a simple way to draw the cursor.
    – john_e
    Mar 31 at 9:11
  • Windows versions before Windows XP did in fact do this, and although the resource editors of the time didn't support it you could manually create such cursors. Although you could XOR with all 1s, I used to just XOR the highest bit, which halved the contrast but made it more consistent.
    – Neil
    Mar 31 at 9:45
  • Actually I checked and I only used them with Windows 95 to Windows 2000, so I can't vouch for earlier versions.
    – Neil
    Mar 31 at 9:49
11

That makes me wonder if there was some reason for it other than individual preferences?

Oh yes!

Historically it even predates modern desktop systems, as the inverted mouse cursor was already part of the original Star design - as a UI feature for better usability. And it was/is really a necessary one. With an inverted 'inner' area, it offers maximum contrast on any image 'below', thus making it best seen. While this may be less of an issue nowadays with crisp clear high resolution and high contrast screens, it was much needed back in the old days. Even hardware, that, back then, seemed like out of this world sharp, like the Xerox workstations, are rather fuzzy when revisited today.

Even worse average screens during 80s and 90s - and to top it early laptops with Plasma/LCD. There is a reason Microsoft added 'animated' cursors with shadow images following the movement (still available today) or little star sprinkle whenever the cursor got moved. All measures to help one find it faster.

In addition to less than perfect hardware, there are less than perfect humans. No matter of by age or otherwise. Maximized contrast does help here as well - but it's hard to see/believe for young folks with good eyes and fast reflexes ... they need to give it a few years to sink in :)

Bottom line, it's a service to enhance GUI ergonomics.

2
  • 1
    Except, see Erik F's comment on tofro's answer; An xored sprite would be practically invisible on a true medium gray background, and would be pretty darned hard to find on a 50% gray pattern on a bi-level screen (Don't ask me how I know!) Mar 30 at 23:18
  • 1
    @SolomonSlow That's why many implementations had a black (and white) outline with only the 'inner' area inverted. Slimilar to black only cursors that (on better UI) always had a white outline. There are multiple effects at work. Edges as well as enhanced contrast
    – Raffzahn
    Mar 30 at 23:26
10

On systems without hardware sprites, this technique allows to avoid storing/redrawing the background without any backbuffer thanks to XOR properties.

On the Amiga, on the other hand, the cursor is made with a hardware sprite. In that case, it's not possible to achieve the XOR effect, but the mouse move takes virtually no CPU. In that case, choosing a very different color than the rest of the windows background is a must have, with a border around the pointer just in case the background is of the same color as the mouse (OCS sprites may have up to 3 colors plus transparent).

Note that XOR style isn't lost in time: Windows 10 still uses XOR style for shadow window outline when windows movement is configured without "move with content".

4

Really it was born out of neccesity.

It was started in the days of monochrome displays. If your only colours are black or white then your options are somewhat limited. Back then, resolutions were not really good enough to have a white pixel and black pixel border around a white cursor like we have today.

As colour displays became more common, the XOR mouse pointer stuck around. Very useful in the early days of colour displays, where you were likely using a domestic 360p TV with a blurry, fuzzy image as a monitor.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.