Re: [OT?] Refresh rates for LCD screens?



jg.campbell.ng@xxxxxxxxx writes:

>My model for CRT displays has a display processor scanning through
>image pixel memory cells in raster order and sending grey level values
>through a digital to analogue converter to produce a voltage which
>somehow modulates the flow of electrons from an electron gun onto
>phosphor painted on the rear surface of the front of the tube; scan
>signals are generated accordingly. For colour, multiply everything by
>three and include shadow masks and red, green and blue phosphor
>patches.

>What is an equivalent refresh model for LCD screens? Assume analogue --
>though I might need an exact explanation of the difference between
>analogue and digital in this context.

In the case of LCD screens, there is local memory *in the LCD
controller* to remember the state of every pixel in the screen.
Because of this, there are two parts to "refreshing" an LCD screen:
getting the data from the computer frame buffer (graphics card) to the
LCD controller, and then driving the LCD panel itself.

The first part of the process is done *as if* the LCD was a raster
device. The pixel data is sent from the computer to the LCD controller
in row/column raster order just as if it was a CRT. If you're using an
analog connection between computer and display, the graphics card
actually generates analog RGB and sync signals just as if it was driving
a CRT - it has no way of knowing the display is actually an LCD. Then
the display controller generates local clock signals locked to the
incoming analog video, and converts the signal back into digital form
before storing the pixel data in the LCD controller memory. If the
frame buffer pixel clock and the LCD controller pixel clock are not the
same, you can end up with pixel jitter artifacts.

On the other hand, if you use a digital (DVI) connection between
graphics card and display, the pixel data is transferred in digital
form, with no noise introduced by D/A and A/D conversion, and without
wasting time for horizontal and vertical sync and blanking periods.
This is more efficient, and avoids the need for the digitizing circuitry
in the display.

Either way, once the pixel information is in the LCD controller, the
controller then uses it to modulate individual pixel cells in the LCD
panel itself. This happens at a frequency that is determined by the
controller and panel's needs, and it's not necessarily synchronized with
the incoming video.

>I know that LCD screens have a 'native' resolution, i.e. that each
>screen pixel corresponds to a single transistor or diode.

Yes. But many LCD monitors contain internal resampling hardware that
will accept an incoming signal at a wide range of resolutions and then
resample that to the actual display resolution. The image tends to lose
some crispness when you do this, so it's generally better to operate at
the native resolution.

>Do we still have raster refresh? I guess flicker and tearing do not go
>away when we have an LCD screen.

The refresh is raster as described above.

The light output from an LCD is continuous; it doesn't come in bright
pulses as the electron beam sweeps over the phosphor like a CRT. This
means that LCDs don't flicker if they are updated slowly from the
computer; 60 Hz refresh flickers visibly on a CRT but not LCD.

On the other hand, tearing is caused when a single displayed image on
screen comes from two different points in time. To avoid this with a
CRT, it's simply necessary to have the video controller swap buffers
(between the previous and next rendered frame) during vertical retrace
so each displayed frame comes from a single point in time. With an LCD,
there's the additional delay between display controller update and
screen update which can complicate things.

>Another question. If 25--30 Hz is good enough for television or movies,
>why the need for 70--85 Hz refresh on computer screens?

With a flickering light source, we can see flicker up to about 72 Hz
when the light is very bright, dropping below 50 Hz when the light is
dim.

Television uses a 25 or 30 Hz complete frame rate, but the image is sent
in interlaced mode: all the even scanlines are sent in the first 1/50 or
1/60 second "field", followed by all the odd scanlines in a second
field. CRTs display this signal in the same way, so the screen is
actually refreshed at 50 or 60 Hz; it just isn't quite the same data
each time. As long as there are no drastic changes between two adjacent
scanlines (and good TV is filtered so there is not), we don't see
flicker.

Movies are shot at 24 FPS, but the projectors use a shutter that
interrupts the light either 2 or 3 times per frame, so the actual
flicker rate on screen is 48 or 72 Hz. 48 Hz is most common, and works
well in most theatres where even the brightest white in the image is not
that bright in absolute terms, and most of the image is much dimmer.
It's common to see a little bit of flicker in the brightest portion of
the image only. 72 Hz shutters are better in small theatres with
particularly bright images; that pretty much eliminates visible flicker.

But computer screens aren't interlaced (anymore), and they are operated
at high brightness, so you need about 72 or 75 Hz refresh rate to avoid
visible flicker.

>Plus, maybe I should ask whether the answer for LCD will do also for
>TFT and plasma?

TFT is just one LCD panel technology; it's not a separate type of display.
Plasma displays are likely very similar to LCDs when it comes to the
computer-display controller connection. Driving a plasma panel takes
very different voltages and current from driving an LCD panel. LCDs use
very low voltage and current to change the polarization state of the
liquid crystals, while the light comes from a separate backlight and two
polarizing sheets actually absorb or pass light. Plasma panels emit
light directly from each pixel cell.

Dave
.