| Date: | August 23, 2005 / year-entry #236 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050823-12/?p=34473 |
| Comments: | 20 |
| Summary: | Icons are all multiples of eight pixels in width. It's not just because computer people like powers of two. Back in the early days of Windows, video cards were monochrome or, if you were lucky, 16-color. These were all planar video modes, the mechanics of which were discussed earlier. Now imagine copying a bitmap to... |
Icons are all multiples of eight pixels in width. It's not just because computer people like powers of two. Back in the early days of Windows, video cards were monochrome or, if you were lucky, 16-color. These were all planar video modes, the mechanics of which were discussed earlier. Now imagine copying a bitmap to the screen where both the bitmap and the screen are planar. If the starting coordinates of the destination was an exact multiple of eight, then the bitmap could be copied via block transfer instructions. On the other hand, if the destination was not a perfect multiple of eight, you had to do a lot of fancy bit shifting to get it onto the screen. This is the source of the If you look at dialog box dimensions from Windows 95 or earlier, you'll find that they are nearly always a multiple of 32 DLUs in width. Since four horizontal DLUs equal one average character width, you had to keep your dialog width a multiple of 32 to ensure that the final dialog size was a multiple of eight. Keeping bitmap widths such that they represented exact byte boundaries was important for performance on the machines of the day. Copying blocks of pixels around was typically performed in three major steps: A thin vertical strip from the left edge of the bitmap to the first byte boundary, then the bulk of the bitmap up to the last byte boundary, and finally a thin vertical strip from the last byte boundary to the right edge. If you kept your eyes open, you could actually see these three stages of drawing occurring. (Like I said, machines of the day weren't all that fast.) Keeping things byte aligned and at byte width meant that the two thin vertical strips had zero width and therefore could be optimized out. Of course, in today's world of 32bpp displays, all these old considerations are largely irrelevant. |
Comments (20)
Comments are closed. |
A lot of the old planar memory modes were not actually planar. The video card just represented them that way. The innovativeness of several graphics programmers led to Modes like X and Z which were definitely nonplanar but performed very well.
In addition, anything over 64kb had to be panned under 16 bit operating systems due to memory limits. DOS usually could address 20 bits worth of memory or 1 megabyte. This was stored in two registers both 16 bits. One was a segment and the other was the offset. The segment was shifted 4 bits and added to the offset.
The problem was that this algorithm actually allowed for more than 20 bits of memory resulting in inconsistent results between earlier and later x86 processors. Intel patched this but this phenomena lead to the High Memory Area.
Those were fun days ;)
Nowadays, 4, 8, or 16 byte alignment for mmx and sse is what’s important for game and video processing, though that’s an edge case compared to system icons. With aligned sse2 access some filters can double or triple their processing speed by eliminating all those extra pixel fixups, when memory and cache bandwidth are the crucial bottlenecks.
Is this also why screen resolutions in Windows XP are limited to widths that are multiples of 8?
Paul: screen resolution aren’t constrained by Windows, it’s all about the video driver
For instance, VMware comes with optimized video drivers for Windows guests, and from version 5 they support arbitrary resolutions automatically adjusted to fill the VMware window
Re: screen resolutions
Screen resulutions are dictated by the physical proportions of monitors. Most (all?) monitors have a with to height ratio of 4:3. Video modes that follow these proportions (640×480, 800×600, 1024×768, etc) have a square aspect ratio, which means that a square drawn on the screen will appear square. Under non square aspect modes, one side will appear longer, even though the number of pixels is the same.
vince wrote:
——————
I mean, Macs don’t have this problem do they? Back in the day they ran on slow hardware, and obviously pre-dated windows.
——————
Think again:
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html
Apple specifies that you should create 16×16, 32×32 and 128×128 versions of your icons. Like Windows, the OS will accomodate other sizes, but you won’t get the best results.
While most displays are 4:3 there are quite a few that are not. My LCD is 5:4 and there’s a lot being manufactured at 16:9 and other widescreen ratios. And there’s a lot of programs (mostly games but some video codecs do it too) that are "smart" and adjust their drawing assuming your display is 4:3 no matter what your resolution.
Brings back memories of Michael Abrash – Zen of Graphics Programming etc ;)
Though I never ended up actually coding for 4 bit (16 color) mode, it allowed me to figure this one out from the topic without having to read the article (which of course was a bonus).
"On the other hand, if the destination was not a perfect multiple of eight, you had to do a lot of fancy bit shifting to get it onto the screen."
Not to mention you would have to read from video memory, a huge performance hit, in order to combine the bit patterns.
Vince wrote:
"So do icons snap to multiple-of-8 offsets when you drag them to the desktop? Are all menus and windows aligned these days so that your icons will be at the proper offset? "
It’s 8 bits, not 8 pixels. On screens with a colour depth of 8-bit (256 colours) or more (i.e. everything these days) it has no effect, since that would be less then one pixel.
I wouldn’t be surprised if the code was no longer present, as less them 256 colours hasn’t been supported for along time.
I’ve made Windows XP do hideous 16-colour displays. You have no idea how happy I was to get the correct video driver reinstalled.
[Quoted from vince]
How many people use black-and-white bitmapped displays these days anyway?
[/quote]
Yes. POS systems nowadays in place like supermarkets still uses 9-inch monochrome CRTs because they’re cheap and they fit their need.
OS developer should take care every hardware that are still in use by lots of people at the time of release, or they just can’t be justified to get them updated.
You are kidding, right Norman? Vista doesn’t allow resizing of it’s dialogs? If this is still around after the betas it will surely be the worst UI design choice I’ve seen from the Windows team in ten years. I’ve come to expect a much higher standard than that.
(The Office team however, is another story alltogether. Remember when Word 97 had a custom-made Open/Save-dialog that didn’t allow resizes? You could only display 8-10 files at once, which meant finding the right file to open could take 30 seconds if you had many documents in the folder. What amazed me most was that they had actually taken the time to design something that had less functionality than the standard dialog that they could have gotten for free. I would have been furious if I was on the Windows team.)
What amazed me most was that they had actually taken the time to design something that had less functionality than the standard dialog that they could have gotten for free.
Office 97 was made when Windows 95 was current, therefore the system dialogs were still fixed size too. It wasn’t until Windows 98 (SE?) when they became resizable.
Wednesday, August 24, 2005 5:35 AM by jojjo
> You are kidding, right Norman? Vista doesn’t
> allow resizing of it’s dialogs?
I’m not kidding. I wouldn’t have believed it if I hadn’t tried it. Since I have an MSDN subscription at present I was able to use the beta bug submission tool to point them to a few screenshots, but who knows if they’ll read or care.
Actually I was amazed that the owner of this blog didn’t pounce on them before I did. Even though this isn’t a .Net blog, I’d have thought Mr. Chen would be pretty outraged by this absurd destruction of the user interface.
Screen resolution: 640×480, 800×600, 1024×768… Why do video drivers generally restrict us to these sizes? You might want to keep the aspect ratio of 4:3 (or 16:9) the same, but let me pick one of the dimensions, so I can have… 900xwhatever, or 1100xwhatever.