Slashdot Mirror
Super LCD Screens: 200 PPI
crovira wrote to us with an article from the NYT (free reg. req'd.) Apparently, both Toshiba and IBM are dissatisified with the current state of monitor development. To that end, they've created some wondrous toys like 16.5" LCD screens that display 200 PPI. They've run into a most curious problem however: Legacy software/drivers. Click thru to read more - and if IBM should want to send a couple screens my way, I'd see what we can whip up around the office *grin*.
"The problem isn't in the display driver!"
Nope, it's the assumptions that programmers make about screen resoultion. The solution might lie in using 'third generation 2d engines' as discussed in a story on slashdot one or two weeks ago. Apple's MacOS X will use such an engine. Basically it's vectorbased graphics they are using. This means that the GUI is resolution independent and that anything you display on it will scale nicely from a ancient 14 inch monitor to a modern laser printer.
It wouldn't surprise me if these screens will be available for mac os X first.
Jilles
The issue at hand is not that "corporate" is not willing to open up the specs. The real problem is the fundamental way most OSes realize their GUI on the display. They were designed with the "traditional" monitors in mind. With new monitors from IBM/Toshiba that supports double the resolution in the same amount of space, everything - icons, menu bars, EVERYTHING looks half as small on the monitor. What we realy need is let go of everything bitmap, and implement the GUI in vector and True Type Fonts.
The problem isn't in the display driver! A good 16 LCD at 80ppi will pull 1280x1024. These folks have upped the resolution to 3200x2400. That's nearly impossible to read even on a 24 inch SGI monitor; everything is miniscule! Imaging trying to read that image, complete with tiny 10pt fonts and 80x80 icons, condensed into 16.5 inches! Thats the problem!
Quake ought to look good on that sucker..
.sig: Now legally binding!
OK. Here's another take. Many newer games using 3D API's have to be written with resolution independence. For instance, on an old 3DFX Voodoo, you're not going to be able to push 30fps in the newest games unless you run at 640x480 or maybe 800x600. But on your brand spanking new GeForce 256 DDR you can do 1280x1024 at like 60 fps.
I don't really understand how everything under the hood works, but it appears to me that when a game needs to display 2D graphics, sprites, or entire 2D UI's, it makes calls to the 3D libraries, loading these graphics as textures that the accelerator can then scale, rotate, and all that other fun stuff. Load up Quake 3 and look at the main menu. The text is the same size no matter what resolution you're at and unless you're in some absurdedly high resolution, it doesn't pixelate, and the graphics card automatically anti-aliases the pixels.
Display Postscript, Display PDF, and other forthcoming display technologies rely a lot on software and still treat the computer display as a raster medium. These will be interim solutions, but if the proper hooks aren't put into these software components for hardware acceleration, things like Display PDF will overrun the processor at very very high resolutions.
How about this? Let's treat the video memory area in the graphics card as a canvas and draw vector graphics in it. These will naturally include bitmaps with physical size information, and even a legacy "raster canvas" mode to accomidate legacy applications. Then all that has to happen is the graphics card does the rasterizing to whatever absurd resolution you need and pipes it to the display.
A few things this implementation has the ability to do:
1) Support everything NOW. In legacy modes, you'd get anti-aliased scaling, much like when I change my resolution on this LCD monitor in front of me to 640x480. Sure, you wouldn't get the benifit of 200 ppi, but at least you would have a crisper screen to look at (one of the things that annoys me most about my flat panel is that you can see the individual Pixels and the grid in between them)
2) Take a lot of the graphics burden off of the CPU -- the performance increase from the modifications made to DirectX 7.0 to accomidate the GeForce and a "GPU" in general really beg for the same kind of GPU idea to migrate back to 2D, where it will be needed to support massive resolutions needed in the future. Gradients, scrolling, and moving entire solid windows and widgets around are some of the most CPU intensive operations that can be done (check your meter while running E with all the bells and whistles on!) This are things that should be done by the video card anyway. Let's see some people start putting hooks in there software and OS's to allow this! Stop thinking in pixels already!
3) Support legacy apps on new software/hardware in the future. Load a rater-drawn app into a texture buffer and a virtual "screen" that has pixel dimensions, then scale those pixels on the canvas appropriately.
So anyway, I guess we'll see now how this idea will hold up.
~GoRK
For example, SGI has long provided scalable icons for its IRIX desktop file manager. Apple's new Quartz graphics API and Aqua GUI look like they may have the start of this flexibility. OpenGL may be a good base to work from as well.
As someone who spends way too much time reading text on computer monitors, I look forward to any improvements in their readability!
Tim