4 ms·

I think from a hardware perspective this would be non-trivial, despite sounding like an obvious thing in principle. In sending the entire frame with every refr

I think from a hardware perspective this would be non-trivial, despite sounding like an obvious thing in principle. In sending the entire frame with every refresh you get pixel addressing "for free", since you just send the data for each pixel sequentially in a predefined order. If you only wanted to update a single pixel, you would need to effectively send an instruction saying "set pixel x to rgb: a, b, c" or whatever, including both the pixel colour values and the pixel address. You'd also need some sort of edge detection for when a pixel is supposed to change which adds a delay. This is fine for one pixel, but if every pixel on the screen changes at once then suddenly you are going to be sending a hell of a lot of instructions that not only contain the colour values as in the "old crt style" method, but also the address of every individual pixel too, which will then have to be decoded by the screen-side hardware. All in all, you'll be using a lot more bandwidth and will need a much faster clock to do all of that in the same period of time. In the old school way, you just have a pixel clock that matches the pixel rate and some serdes for serialisation/deserialisation on each end which imo is considerably simpler.

scoutt 4y ago
If you don't send the entire buffer then a monitor should have at least 6220800 bytes of RAM dedicated to the frame buffer (1920x1080 resolution), do auto refresh (standard 60Hz) on the panel, and accept commands to overwrite said memory with new data, partially or completely. That solution is far from what we have now, and much more like a serial LCD controller.
amelius 4y ago
I think people can come up with more efficient protocols than sending x,y,rgb for every pixel. What you call "edge detection" is not necessary if you use shadow buffers. Yes, the display would need some memory, but this is measured in tens of megabytes which is not much by today's standards.
- dahart 4y ago
  Seems like having memory embedded in the display for a shadow buffer, and the diffing algorithm you’re proposing, could easily undo any power savings you’d get, and then some. Why are you certain that saving power is simple? How much power does the data protocol consume compared to the display itself? Isn’t the data transmission power in the noise margin of the power requirements for an active display, CRT or LCD?
  - deleted 4y ago
    [deleted]
- tverbeure 4y ago
  * a sink side memory of tens of megabytes is either on-chip memory (very costly) or on-PCB DRAM (still costly). For high refresh rate monitors, the memory would need to be high BW too. Note that there aren't any modern memory standards that are high BW but low storage. DRAMs with just a capacity of just a few MB would be very much pad limited. * source side, you'd need a shadow buffer as well, and you need double the read BW to detect the difference between previous and the current frame. All of that is technically achievable, but none of it matter for desktop monitors: the power savings are just too low to matter. Laptops are a different matter. Many laptop LCD panels already support self-refresh. (Google "Panel Self Refresh") But that's for cases where the screen is static: the user is staring at the screen, not moving their mouse, the cursor is static. The benefit is not just putting the link but also putting the GPU to sleep. That's the low hanging fruit. Partial screen update doesn't save a lot more, because you'd need to power up the GPU for that.

scoutt 4y ago

If you don't send the entire buffer then a monitor should have at least 6220800 bytes of RAM dedicated to the frame buffer (1920x1080 resolution), do auto refresh (standard 60Hz) on the panel, and accept commands to overwrite said memory with new data, partially or completely. That solution is far from what we have now, and much more like a serial LCD controller.

amelius 4y ago

I think people can come up with more efficient protocols than sending x,y,rgb for every pixel. What you call "edge detection" is not necessary if you use shadow buffers. Yes, the display would need some memory, but this is measured in tens of megabytes which is not much by today's standards.

dahart 4y ago
Seems like having memory embedded in the display for a shadow buffer, and the diffing algorithm you’re proposing, could easily undo any power savings you’d get, and then some. Why are you certain that saving power is simple? How much power does the data protocol consume compared to the display itself? Isn’t the data transmission power in the noise margin of the power requirements for an active display, CRT or LCD?
- deleted 4y ago
  [deleted]
tverbeure 4y ago
* a sink side memory of tens of megabytes is either on-chip memory (very costly) or on-PCB DRAM (still costly). For high refresh rate monitors, the memory would need to be high BW too. Note that there aren't any modern memory standards that are high BW but low storage. DRAMs with just a capacity of just a few MB would be very much pad limited. * source side, you'd need a shadow buffer as well, and you need double the read BW to detect the difference between previous and the current frame. All of that is technically achievable, but none of it matter for desktop monitors: the power savings are just too low to matter. Laptops are a different matter. Many laptop LCD panels already support self-refresh. (Google "Panel Self Refresh") But that's for cases where the screen is static: the user is staring at the screen, not moving their mouse, the cursor is static. The benefit is not just putting the link but also putting the GPU to sleep. That's the low hanging fruit. Partial screen update doesn't save a lot more, because you'd need to power up the GPU for that.