The Power Of Refresh Rates

[Nappe1]

wow wow, guess what I am able to pull out of this discussion??

BITBOYS! (suprise, suprise!)

G10 that NEC is using on their mobile LCD panels is just done for reducing data transfers between LCD controller and actual panel. G10 accepts SVG commands and draws them directly to the screen, so that only SVG drawing commands is need to send via bus and the G10 does the rest of the stuff. This reduces the amount of used bandwidth quite bit, because the bus isn't used for timed screen refreshes, but for controlling panel itself what it displays.

The Idea of updating screen only when it changes has been bothering me too and it could be taken even further by dividing the LCD panel to macro and micro blocks, so that only modified elements could be sent over (ala MPEG encoding/decoding.) this would reduce the bandwidth even more which again could translate to power consumption of the screen.

 

[philoni]

You'd want to run q3 at the highest quality you could get at 125 fps because of the speed rounding bug.

 

[Fox5]

LCD's that refresh when told rather than expecting a signal every 1/60th of a second already exist. Generally they are in the mobile area where power consumption is a priority, as only sending the data when it changes is a big saving, especially on something like a phone where the display will not be changing for much of the time.

CC

Nintendo's handhelds might work like that, or at least I've heard that the DS doesn't have a framebuffer, and I don't think there would be any need for a framebuffer if you're drawing directly to the screen. While saving on ram might not matter too much to PC video cards, I'd imagine it matters a lot of a handheld where the ram is measured in kilobytes. BTW, was it ever revealed who developed the graphics hardware powering the DS? Heck, who's fabbing the cpu?