Hacker Newsnew | comments | show | ask | jobs | submitlogin

It's interesting to see how misinformation propagates.

The second-highest-rated answer on Stack Exchange (46 votes and climbing) claims that another reason for the left arrow cursor in early GUIs was to put the hotspot at (0,0) to save time in the mouse position calculations:

http://ux.stackexchange.com/a/52349/43259

The answer cites this Reddit comment as its source:

http://www.reddit.com/r/explainlikeimfive/comments/1qhzym/wh...

That comment is a direct copy of this Yahoo! Answers comment from 2009, which says that the Xerox Alto worked this way, but cites no source for the claim:

http://answers.yahoo.com/question/index?qid=20090520113724AA...

In fact, the Alto did have multiple cursor shapes, and the hotspot wasn't always at (0,0). For example there was this cross in a circle:

http://www.guidebookgallery.org/articles/thexeroxaltocompute...

and a right-pointing arrow:

http://toastytech.com/guis/saltobravo.png

Let's ballpark the CPU overhead. According to this article, the Alto executed about 400,000 instructions per second, with an instruction set modeled after the Data General Nova 1220:

http://www.guidebookgallery.org/articles/thexeroxaltocompute...

Here's a brief description of the Nova instruction set:

http://users.rcn.com/crfriend/museum/doco/DG/Nova/base-instr...

There are four accumulators, with an ADD instruction that adds one accumulator to another (and a similar SUB). There are LDA and STA instructions that load and store memory, addressed with a displacement and an optional accumulator (e.g. to access into a structure using a pointer).

It seems reasonable to assume that at some point in the mouse refresh code, we will have the mouse's X value in one accumulator, and a pointer to the cursor structure (containing the cursor bitmap, hotspot, etc.) in another.

So to adjust our X value using the hotspot X from our cursor structure, we simply need an LDA to load the hotspot X into another accumulator, and an ADD or SUB to do the calculation. Repeat that for Y, and we've added a total of four instructions.

At 400,000 instructions per second, these calculations would add a 1/100,000 second overhead to the mouse calculation.

A worst case might be that we don't have a free accumulator when we need it. So that would be another STA and LDA to spill one temporarily.

If we have to do that for both X and Y, it would put us at eight instructions total, or 1/50,000 second.

Still probably worth doing it to get the flexibility of custom cursor hotspots. :-)




Nice digging.

This hit the BS detector for me too, mainly because it goes against some of the rules of thumb I have found useful for optimization. For example, the need for smooth and stutter-free ui notwithstanding, if something only happens in response to user input you are less likely to see important gains from this sort of CPU microoptimization. Even on a very old machine, it should be obvious that the computer adds integers much faster than you can move your finger (otherwise there would be no point of having the computer, am I right?) On the other hand, if you had to compute more on every frame or for a substantial amount of onscreen objects, that's where the real gains are going to live, because the numbers add up much more easily.

-----


how much is 4 or 8 or even 16 instructions compared to the amount of time to actually draw the cursor graphic into the frame buffer?

-----




Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: