3 ms·

Why can't a display behave exactly as bit-mapped memory? That is, you set this pixel in memory, and that pixel changes on the screen, at that time. That is, li

by 6ren 13y ago

Why can't a display behave exactly as bit-mapped memory? That is, you set this pixel in memory, and that pixel changes on the screen, at that time. That is, like a vector display, but using the LEDs of a flat screen. There's no electron ray scanning over the phosphors as there was in a cathode ray tube. -- The LEDs can switch only so fast - but does this latency prevent them from being switched independently? The LEDs need to stay on for long enough for the human visual system to perceive them (and without flickering etc) - but this could be managed in other ways. I think the main reason, apart from inertia, is that the larger market for displays is as TVs, where the concept of updating the whole frame (frames per second) is even more entrenched - though, there's no reason why video couldn't be displayed in the same way, it's just pushing out a kind of compression to the display itself. Light from real objects is not emitted one frame at a time.

YZF 13y ago
I assume you're talking about LCD? Not too many LED displays around (though the principle is still similar). While there's no scanning electron beam the electronics on these displays are still optimized for scanning. That is they push a whole bunch of adjacent pixels in every clock cycle. If you try to use those for random access your refresh rate is going to fall dramatically. The problem isn't whether or not each pixel can be switched independently it's how to efficiently address them and move data from the display controller to the display. (editing with some more info) If you changed the monitor's protocol to push X, Y, pixel and souped up the on-board electronics your pixel rate would probably fall by an order of magnitude. So your 80Hz display is now an 8Hz display (for full frames). In terms of how each pixel behaves they are independent (each has it's own transistor and capacitor) but the addressing is on a grid. So you can select your row and then set a whole bunch of pixels in this row (for example)...
- asharp 13y ago
  That doesn't seem to agree with http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgrounder.pdf http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgroun... .
  - YZF 13y ago
    What specifically do you have a problem with? Details will vary between different displays but my point is that due to the pixels being on a grid sequential access is going to be faster. This is not unlike memory. EDIT: Here's a reference that discusses scanning in a TFT: http://www.electronicsforu.com//EFYLinux/efyhome/cover/March2010/TFT-LCD_Mar2010%284%29.pdf http://www.electronicsforu.com//EFYLinux/efyhome/cover/March... "The TFT-LCD panel of the AMLCD is scanned sequentially line-by-line from top to bottom. Each line is selected by applying a pulse of +20V to gate line Gn, which turns on the TFTs in that specific row. Rows are deselected by applying –5V to G n-1 and G n+1, which turns off all the TFTs in the deselected rows and then the data signal is applied from the source driver to the pixel electrode. The voltage applied from the source driver, called ‘gray-scale voltage,’ decides the luminance of the pixel. The storage capacitor (CS) maintains the luminance of the pixel until the next frame signal voltage is applied. In this way, the next line is selected to turn on all the TFTs, then the data signal is fed from the source driver and hence scanning is done."
    - wtallis 13y ago
      Selecting rows like that is very similar to how DRAM works, just with the word size being the number of subpixels in a row, and with no read port. Bit-level random access is inefficient, but you don't have to write to the rows in sequential order, and you don't have to update all the other rows before issuing another update for the first row. That's purely a limitation of the current driving circuitry, but a replacement like G-SYNC doesn't have to be bound by sequential rasterization any more than it has to stick to a fixed refresh rate.
    - buster 13y ago
      But it's most likely working that way because (analog) displays always worked like that and your display technology needed to be as compatible as possible for CRTs and TFTs. From my point of view you have not explained why it's not technologically feasible. You're merely describing that the current display tech isn't working that way.. of course not..
      - 13y ago
kyberias 13y ago
Because of overhead. It's much slower to communicate "turn pixel at X,Y on" to the display for millions of individual pixels than it is to communicate "here's all the millions of pixels you need to display in sequence" in one message.
ye 13y ago
Because telling the display to turn one pixel at a time will require crazy bandwidth, and plus that's not how monitors or videocards or drivers or software work.

by 6ren 13y ago

YZF 13y ago

I assume you're talking about LCD? Not too many LED displays around (though the principle is still similar). While there's no scanning electron beam the electronics on these displays are still optimized for scanning. That is they push a whole bunch of adjacent pixels in every clock cycle. If you try to use those for random access your refresh rate is going to fall dramatically. The problem isn't whether or not each pixel can be switched independently it's how to efficiently address them and move data from the display controller to the display. (editing with some more info) If you changed the monitor's protocol to push X, Y, pixel and souped up the on-board electronics your pixel rate would probably fall by an order of magnitude. So your 80Hz display is now an 8Hz display (for full frames). In terms of how each pixel behaves they are independent (each has it's own transistor and capacitor) but the addressing is on a grid. So you can select your row and then set a whole bunch of pixels in this row (for example)...

asharp 13y ago
That doesn't seem to agree with http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgrounder.pdf http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgroun... .
- YZF 13y ago
  What specifically do you have a problem with? Details will vary between different displays but my point is that due to the pixels being on a grid sequential access is going to be faster. This is not unlike memory. EDIT: Here's a reference that discusses scanning in a TFT: http://www.electronicsforu.com//EFYLinux/efyhome/cover/March2010/TFT-LCD_Mar2010%284%29.pdf http://www.electronicsforu.com//EFYLinux/efyhome/cover/March... "The TFT-LCD panel of the AMLCD is scanned sequentially line-by-line from top to bottom. Each line is selected by applying a pulse of +20V to gate line Gn, which turns on the TFTs in that specific row. Rows are deselected by applying –5V to G n-1 and G n+1, which turns off all the TFTs in the deselected rows and then the data signal is applied from the source driver to the pixel electrode. The voltage applied from the source driver, called ‘gray-scale voltage,’ decides the luminance of the pixel. The storage capacitor (CS) maintains the luminance of the pixel until the next frame signal voltage is applied. In this way, the next line is selected to turn on all the TFTs, then the data signal is fed from the source driver and hence scanning is done."
  - wtallis 13y ago
    Selecting rows like that is very similar to how DRAM works, just with the word size being the number of subpixels in a row, and with no read port. Bit-level random access is inefficient, but you don't have to write to the rows in sequential order, and you don't have to update all the other rows before issuing another update for the first row. That's purely a limitation of the current driving circuitry, but a replacement like G-SYNC doesn't have to be bound by sequential rasterization any more than it has to stick to a fixed refresh rate.
  - buster 13y ago
    But it's most likely working that way because (analog) displays always worked like that and your display technology needed to be as compatible as possible for CRTs and TFTs. From my point of view you have not explained why it's not technologically feasible. You're merely describing that the current display tech isn't working that way.. of course not..
    - 13y ago

kyberias 13y ago

Because of overhead. It's much slower to communicate "turn pixel at X,Y on" to the display for millions of individual pixels than it is to communicate "here's all the millions of pixels you need to display in sequence" in one message.

ye 13y ago

Because telling the display to turn one pixel at a time will require crazy bandwidth, and plus that's not how monitors or videocards or drivers or software work.