Adjustable Lcd Refresh Rate?

[Immerman]

Hi all,

I was wondering what exactly the refresh rate on the LCD will be, and whether it will be possible for a program to adjust it. A forum search turned up a couple posts suggesting it might be, but nothing definite.

I'm playing with the idea of making a speed-reading program - one of those "flash one word at a time on the screen" jobs. However, the word rate is intimately tied to the refresh rate of the screen - there's no possible way to display a word for 3.7 frames for example. That means as you get faster you have to make increasingly large jumps in reading speed - for example, at 60 frames per second the possible high speeds are 600, 720, 900, 1200, and 1800 words per minute. And personally while I can sometimes make the jump to 900wpm, the jump to 1200 is just too much for me to manage. (Yes, I left out 1 frame per word, =3600wpm. Staring at a flickering screen while subliminally reading Alice in Wonderland just seems like it would be a bad idea)

So my idea is that if I could vary the refresh rate I could fill in the gaps a bit, especially if it could refresh at "strange" speeds like 55Hz - that would add in rates of 660, 825, 1100, and 1650wpm, providing much more manageable jumps. And obviously the more refresh rates available the smaller the steps could be.

So, does anyone know if this is possible?

 

[CME]

hi, i'm also intrested in this, if the LCD refreshrate is adjustable, because of PAL videos and PAL games in emulators, i don't like the framerate converting from 25fps/50fps to 60fps

 

[palmertech]

The screen is set to 60hertz, AKAIK.

 

[Swiss_Cheeseman]

Can a dev speak up? An Amiga emulator would greatly benefit from a 50hz mode (among other things) due to a lot of software being developed for use in Europe.

 

[nate9771]

i think craig said somthing like this"the pandora will have a screen simaler to the psp".

ps sry for bad spelling

 

[Pleng]

i think craig said somthing like this"the pandora will have a screen simaler to the psp".

ps sry for bad spelling

No. The PSP screens seems to be pretty-much disliked on this forum (I've hardly ever used one so I dunno about that). The screen is the same as that found on one of the more recent Archos players. Not sure which one. A search on the forum for Archos should get a decent result

 

[azmodean]

You have a bit of a misunderstanding, unlike CRTs LCD panels don't have a refresh rate, what they have instead is a response time, which according to MWeston is 30ms. So at least theoretically you could do around 1980 WPM without bleeding, which is a bit higher than your listed target. From my experience with writing a similar app for the gp2x [plug]rsvp4gp2x[/plug] there should be NO problem driving the text to the screen at that speed (while doing a bunch of other things simultaneously for that matter).

Also, you'd better do it right or I'll port my app and steal all your users

 

[CME]

but the graphic card still sends x pictures per second to the LCD, and setting this to 50hz would be nice

 

[azmodean]

That might be a point, I doubt there is some fixed clock at which the screen gets updated, but the bottleneck for how often the screen gets refreshed might not be in the LCD. That would probably be more a a developer-level question, so we'll see if we can get an answer at some point.

By the way, the 30ms I mentioned was the time it takes a pixel to do black -> white -> black, just black -> white or white -> black would be more like 15 ms, so the screen response shouldn't be an issue for this application (probably video playback too, not sure about that)

 

[Squidge]

You have a bit of a misunderstanding, unlike CRTs LCD panels don't have a refresh rate, what they have instead is a response time

Unfortunately, you can't tell the LCD to "Go to pos x,y and set that pixel to green" - they still need an entire screen each time you want to update the picture. A lot of LCDs are "forgetful" if you just update once then stop sending them data, so you have to give them a constant feed. You could do it 100 times a second, but that's a bit wasteful as it just burns memory bandwidth, so most OS's just treat the LCD as a CRT and update the usual 60 times a second (60Hz).

Of course, if you decide to update the frame buffer whilst it's being uploaded, you can get tearing. So you either attempt to match the display refresh with your frame buffer update, or vice versa. Most programs opt for the later.

 

[Tinnus]

Would be great if we had an API for that though

 

[MilanC]

Yes... switch between 50 and 60 fps would be nice; having 24, 25 and 30 fps, too, would be even better, saving memory bandwidth and corresponding to common video frame rates.
Saving 30MB/s might not seem a big deal, but running at the exact frame rate of the video might help?

I don't know a lot about that, but updating the display less frequently might be useful for power-saving, too? (maybe a few extra minutes?)



/me hopes for a 50MHz CPU 12fps screen half-of-minimum-backlight-setting brightness mode, with 32MB of RAM only powered...

 

[basicmark]

Depending on the clocking scheme it might be possible to adjust the pixel clock and thus the refresh rate of the LCD. The Linux framebuffer API allows applications to this (using IOCTLs) but the support would have to be added to the LCD driver (if it isn't already there).
From the LCD controllers point of view you should be able to set the refresh rate to what ever you like, but at lower refresh rates you notice the flicker a lot more (I've had a 800x640 LCD running at 12.5fps and it was still readable but not very pretty ).

 

[MilanC]

Thanks

I don't get why there would be some flicker on an LCD at low frame rates, though? (except if the backlight flickers, of course.)

 

[MWeston]

Some of you are confusing fps in an application with the vertical sync time of the LCD. Sure you can run your application at whatever frame rate you want, but the LCD wants a minimum of 50Hz to keep the transistor gates energized long enough to prevent too much leakage before the next refresh (ie. flickering).

Setting the LCD to 24 fps because the video is 24 fps is a terrible idea. It is better to let the same image scan repeatedly before the next video frame rather than starve the transistors of gate drive. This is why Sharp and everyone else is getting on the bandwagon for 120Hz refresh, not that I think that little gimmick is really doing that much personally.

 

[Squidge]

The problem is, people see LCD as not needing a refresh as theres no phosphor needed to refresh the screen.

Also, (understandably) if your app runs at 50fps, but the LCD runs at 60fps, as you want to ensure zero tearing by syncing with the vblank of the LCD refresh, then there will be a lot of time wasted which could have been used for other things. Plus of course you'll usually end up with updating your frame buffer @ 30 fps.

 

[fanoush]

Setting the LCD to 24 fps because the video is 24 fps is a terrible idea. It is better to let the same image scan repeatedly before the next video frame rather than starve the transistors of gate drive.

No it is actually great idea. Too bad it wouldn't work as expected at low refresh rates due to the HW limits you explained. If it worked it would also possibly save SDRAM bandwidth a bit.

Since it is impossible to emulate e.g. fluent 50 fps PAL video output when LCD refresh is set to 60Hz, it would be nice to have it configurable at least between 48(=2x24) and 60.

EDIT: I mean full interval so we could set 50.12Hz for c64 emulation.

 

[basicmark]

Some of you are confusing fps in an application with the vertical sync time of the LCD. Sure you can run your application at whatever frame rate you want, but the LCD wants a minimum of 50Hz to keep the transistor gates energized long enough to prevent too much leakage before the next refresh (ie. flickering).

Sorry, your right, I should have said Hz, not fps . It's interesting that many people seem to assume that LCD's don't have a minimum refresh rate (I'm not just talking about these forums, but in general), where as most people understand that CRTs do have these limitations. I guess that CRTs have been around that much longer and are thus better understood then LCDs.

 

[Squidge]

Some LCDs do have a frame store, so you could run them at 1Hz if you really wanted to, but I see to recall that they are slower overall than the ones without the store. Maybe they are old and not researched so much as they are mainly for specific purposes not requiring a lot of updates. I don't know. All that matters how is that the Pandora's LCD has a minimum refresh rate.

 

[Immerman]

Okay, so it sounds like the LCD and driving circuitry can theoretically be clocked to whatever you want, between the minimum and maximum frequencies determined by the hardware capabilities (leakage, response times, etc.) And I would assume the frequency options have a certain granularity due to available clock frequencies, so even if it can hit 45Hz and 50Hz, it can't hit 47.3947328Hz, but that's pretty much a non-issue unless it's really, really rough.

So I guess my questions are
1) Can the specific hardware in the Pandora be configured to update the LCD at various frequencies, or is it locked to 60Hz (or whatever Hz it uses).
2) If so, will it be possible to reach some/many of these other frequencies from within the standard OS without jumping through all sorts of hoops. f.ex. Could my program simply request to run "full screen 800x480x50Hz" mode" the same way I could request "f.s. 800x480x60Hz" or the low-bandwidth "fs 400x240x60Hz" mode.

Could I get an official answer to at least (1)? I assume that if the answer is yes then it's a question of what modes the driver reports as available, and I'd like make a heartfelt request to have at least one "unusual" mode inserted, something maybe 10% off a standard frequency? (Or 120Hz, I could be happy with that)





To those saying I shouldn't have bandwidth issues - I agree completely, that's not the issue. The issue is the number of possible frequencies at which words could change "cleanly", not the maximum.

For reference I present the following table of WPM rates that are possible to display on a screen with various frequencies, depending on how many frames each word is displayed for. If the WPM rate isn't in the chart, it can't be done cleanly - all intermediate word rates would result in either tearing or need the insertion of some sort of transition frames where two words were blended together, neither of which is conductive to easy reading.

Hz Frames word is displayed for
- 1 2 3 4 5 6 7 ...
48 2880 1440 960 720 576 480 411.4
50 3000 1500 1000 750 600 500 428.6
55 3300 1650 1100 825 660 550 471.4
60 3600 1800 1200 900 720 600 514.3
120 7200 3600 2400 1800 1440 1200 1028.6 900 800 720 654.5 600 ...


So might I suggest the following modes be available in the standard shipping drivers?
60Hz - standard, compatible with US system emulation
50Hz - standard EU, compatible with EU system emulation
120Hz - frame-division mode, can be used to easily switch between 60, 40, 30, 24, 20, 17.4, etc. on the fly by repeating frames.

Even if the LCDs response time isn't fast enough to actually display anything at 120Hz, it would still be incredibly useful for things like seamless 24fps movie playback (no frame repeating tricks) and giving graphics-intensive games a lot more framerate options - a nice smooth 40fps looks a lot better than having every other frame shown twice because you can't quite hit 60fps, even though the number of frames rendered is actually lower (40 vs 30+15 = 45). The difference is even more dramatic at lower rates - a nice smooth 24fps is still just above the perception threshold, whereas 30fps that regularly dips to 15 (or even only 20) suffers from obvious stuttering.

Note that I'm assuming the LCD responds the same way to a 60Hz refresh rate as it does to a 120Hz rate where the display is only changed every other frame. I don't now if that's the case. I also don't know what the penalty on battery life would be.