I have some unsolicited advice from an armchair engineer to Apple.
Microsoft is planning for the eventual advent of much higher-resolution LCD panels that we currently have. Their next major operating system release will be entirely vector-based, not tied to the pixel or any specific resolution. However, Microsoft’s next release isn’t scheduled until 2006.
Apple already has a vector-based resolution independent user interface that has been maturing for several years. Apple also has control over the hardware (something Microsoft is starting to get right with their Athens PC specs).
Clearly, price is the hurdle in delivery higher resolutions LCD panels – but Apple sells a high-end product to a market that is willing to pay a premium. I think I might be persuaded to buy an Apple if it came with a 17” or 18” display with a 3200 by 1800 pixel resolution (or higher). At that point, text starts to become as readable on screen as it is on the printed page.
One issue that they would have to deal with if they did jump to a resolution like that is those elements that are inevitably pixel-based. While the primary user interface controls are scalable, some applications would surely have some pixel-based elements implemented.
The most important pixel-based element would be the web. While good CSS and web fonts would thrive in a high-res environment, our trusty GIFs, PNGs, JPEGs, and any pixel-specified fonts or CSS elements would be minuscule. On a 200dpi screen 12-pixel Times New Roman would be less than 1/16th-inch tall.
Perhaps a high-resolution aware web browser could scale the page elements up to a reasonable size. Of course, quality would suffer but if your resolution takes a large enough jump, you could double the size of web graphics and things would look at least as good as they do on our 2003 screens.
I could hack together my own setup right now. IBM is selling a 22” LCD with a native resolution of 3840×2400 ($7,500USD as of this writing). A graphics card (or several graphics cards) to power that kind of resolution would also cost a premium. Even then, I’d be stuck running operating systems that might let me scale the font size up, but a typical website (800 pixels wide) would only be about 4½” wide. I’d also have to get a much better digital camera.
Apple is in a position to pull together the hardware (LCD and graphics card) and software (OS X with Quartz + website magnification in their own Safari browser). If they could pull it off for an anywhere reasonable price (maybe $6,000 for a computer and screen), they would take a giant leap ahead of any other platform.
You’re not the only one (or even the only Steven – try saying that three times, fast!) who’d buy a Mac for that reason, Steven…
Although I would love to see what my preview copy of Longhorn (which is on its way from MSDN as I write this) could do with that (if anything at all…).
Roll on the days that Athens is more than a city and a concept for a computer, and that IBM-Compatible/80×86(-64) machines look as good as Apples.
Then maybe I can win a debate on whose computer is more likely to attract women (or not, as the case may be)!
It’s a little known fact that the “pixels” that the CSS specifications refer to aren’t, in fact, pixels in the traditional sense:
“Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values.”
— http://www.w3.org/TR/REC-CSS2/syndata.html#length-units
Unfortunately, browser vendors ignored this part of CSS and treated them like normal pixels. The problem of high resolutions regarding px font sizes wasn’t actually a problem with CSS, but rather Internet Explorer, Mozilla, etc. Unfortunately, from what I’ve heard, it’s pretty difficult for applications to get the relevent information to do the right thing in terms of CSS. If you ask me, it was a mistake to have some weird redefinition of “pixel” in CSS in the first place.
The answer to higher-resolution screens isn’t to force applications to be aware of the issue and “scale up as needed”. Apple has the opportunity to implement a system-level solution… break apart resolution setting:
1) the resolution of the signal sent out to the display
2) the resolution of the canvas to which the interface is drawn
Quartz drawing commands would be transformed from the coordinate system of the canvas to the coordinate system of the display. Graphics defined as vector would benefit from higher resolution, pixel-maps would not.
This sort of functionality already exists in the form of resolution-switching for LCD displays (which have only one “native” resolution) and in the Universal Access Zoom feature in Mac OS X, which I personally love for making my life easier (although I don’t have vision problems, I use it all the time for watching those tiny movies embedded in web pages, and for zooming out the interface surrounding some document (Word or PDF, for example) so that I and others can more easily read it from a distance).
Marcin
Just to let you know, this article has made the big time… it’s on Mac Surfer Headlines today.
Somewhat relevant to this: Apple released a 20″ iMac today.
I’m not sure how seriously to take these reports, but several Mac rumor sites (there is a whole underworld of mac rumor websites – it’s odd and intriguing), but some are reporting that large and high-res (maybe 30″) LCD panels maybe coming from Apple soon.
I can certainly see them doing this on the hardware side, but I’m particularly curious to see how they hand the side effects of high-res on the software side (web-graphics being tiny, etc.) – though if the screen is large enough, it’s not really higher resolution – just more real-estate (which is not what I’m looking for).
While Quartz is indeed the basis of OS X’s GUI, and it is indeed a vector-based drawing standard, the Os X interface itself is mostly bitmap. All of the GUI objects are bitmaps, although they could easily create new ones for higher pixel-density displays.