Display: Difference between revisions

From OLPC
Jump to navigation Jump to search
(→‎for the programmer: Updated to reflect my current understanding.)
(needs cleanup)
Line 26: Line 26:
=== for the programmer ===
=== for the programmer ===
''(needs cleanup)''
''(needs cleanup)''
The frame buffer is always 1200x900. 200 dpi. Always. What that 200dpi looks like will vary a great deal depending on lighting. Lit externally, you see the actual grayscale pixels on a 1/200 inch grid. Lit internally by the backlight, those pixels become colored. Depending on the ratio of external to internal lighting, the pixels vary from pure gray (black-to-white), to tinted, to pure color (black-to-... red, green or blue, depending on the pixel). Software has to care about the color "mode" (an unfortunate term, since it's a continuum) because of appearances. In gray, a white pixel looks just like its white neighbors. In color, it very much doesn't. If you draw a line one pixel wide, it will look fine in pure grayscale, and oddly dashed and colored in pure color. And in between... in between. Same thing for fonts. The smallest font you can read in pure grayscale will be illegible in pure color. In between, it might be barely readable but surrounded by odd color artifacts. Visually, the effect is that you have lower resolution to play with, so your software, intending to be readable, has to draw small things bigger. Either all the time, or by noticing the current backlight setting and adjusting. It can make things bigger by scaling up everything (overkill, but cairo makes it simple), or only scaling up only the small things. But apparently, in practice, you only need to worry about tiny fonts, and thin, ~1 pixel, diagonal lines.
The frame buffer is always 1200x900, 200 dpi. Always. What that 200dpi looks like varies a great deal depending on lighting. Lit externally, you see the grayscale pixels on a 1/200 inch grid. Lit internally (by the backlight), the display gains color. Depending on the ratio of external to internal lighting, the pixels vary from pure gray (black-to-white), to tinted, to pure color (black-to-... red, green or blue, depending on the pixel).

Software that uses color has to care about the color "mode" (an unfortunate term, since it's a continuum) because of appearances. In grayscale, a white pixel looks just like its white neighbors. In color, it very much doesn't. If you draw a [colored] line one pixel wide, it may look fine in pure grayscale, and oddly dashed and colored in pure color. And in between... in between. Same thing for fonts. The smallest font you can read in pure grayscale may not be readable in pure color. In between, it might be readable but with color artifacts. Visually, the effect is that you have lower resolution to play with, so your software, intending to be readable, has to draw small things bigger; either all the time, or by noticing the current backlight setting and adjusting. It can make things bigger by scaling everything (overkill, but Cairo makes it simple), or scaling up only the small things. In practice, the tricky things are small fonts and thin (1-3 pixel) diagonal lines.


== Todo ==
== Todo ==

Revision as of 22:36, 23 June 2007

This article is a stub. You can help the OLPC project by expanding it.


See Hardware specification#Display.

Understanding the screen

The screen is composed of several layers. Starting at the back, there is a white LED backlight, a 1200x900 grid of color filters, a semi-reflective layer, and a 1200x900 LCD.

The brightness of the backlight can be adjusted. It has (how many?) settings, including off. (include an image of the backlight control)

The semi-reflective layer both reflects room light, and lets the backlight's light out. How much you see of each, depends on the relative strength of the two light sources.

  • In direct sun, you see only reflected light. The backlight setting doesn't matter.
  • In a completely dark room, there is no reflected light. So you only see the backlight, and if you turn it off, you see nothing.
  • In between, you see some mix. You see more backlight if you turn down the room lighting, or you raise the backlight setting. You see less backlight when the room gets brighter, or you lower the backlight setting.

All color is created by the backlight and filters.

There are 1200x900 pixels. Each one has a single colored filter behind it. So each pixel is capable of either R, G, or B. Only one. It relies on its neighbors to provide the others. So each pixel has:

  • a fixed hue (R, G, or B),
  • a value which can be set (still 18 bit (6,6,4), or now 24 bit (8,8,8))??
  • and a chroma[1] which depends on the relative strength of the room light and backlight.

Consider a single one of those 1200x900 pixels. A red one. If its value is 0, black, then lighting doesn't matter. If its value is 255 (or whatever, fully transparent), then in bright sunlight you see only white, and in a dark room you see fully saturated red. If its value is in between, in bright sunlight you see a gray, and in a dark room you see a grayed (ie desaturated) red.

for the programmer

(needs cleanup) The frame buffer is always 1200x900, 200 dpi. Always. What that 200dpi looks like varies a great deal depending on lighting. Lit externally, you see the grayscale pixels on a 1/200 inch grid. Lit internally (by the backlight), the display gains color. Depending on the ratio of external to internal lighting, the pixels vary from pure gray (black-to-white), to tinted, to pure color (black-to-... red, green or blue, depending on the pixel).

Software that uses color has to care about the color "mode" (an unfortunate term, since it's a continuum) because of appearances. In grayscale, a white pixel looks just like its white neighbors. In color, it very much doesn't. If you draw a [colored] line one pixel wide, it may look fine in pure grayscale, and oddly dashed and colored in pure color. And in between... in between. Same thing for fonts. The smallest font you can read in pure grayscale may not be readable in pure color. In between, it might be readable but with color artifacts. Visually, the effect is that you have lower resolution to play with, so your software, intending to be readable, has to draw small things bigger; either all the time, or by noticing the current backlight setting and adjusting. It can make things bigger by scaling everything (overkill, but Cairo makes it simple), or scaling up only the small things. In practice, the tricky things are small fonts and thin (1-3 pixel) diagonal lines.

Todo

other things which should be mentioned:

  • the Browse activity magnifies webpages, since many assume something more like 75 dpi than 200 dpi. (how much is the zoom?)
  • the DCON plays games to minimize color artifacts.
  • there are some "effective resolution in color" estimates at the end of Talk:Hardware_specification#Display_characterization_.28as_we_outsiders_understand_it.29.
  • there is some old software around to fake what a screen image might look like in color. But it doesn't do DCON optimizations.
  • emphasize "can read in sunlight", and why, in constrast to all other laptops. link to wiki 'unique xo technologies' page.
  • talk about power saving, including turning down refresh rate, and dynamically turning off sections of the screen.]
  • ... what else?

See also


This page needs clean-up and editing for coherence, clarity, and completeness.

Please improve this article if you can.

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Display&oldid=45725"