[Qt-interest] Flicker with QtEmbedded-4.5 on arm/Davinci platform

[Abdelrazak Younes]

Oliver.Knoll at comit.ch wrote:
> Abdelrazak Younes wrote on Thursday, January 29, 2009 3:37 PM:
> 
>>> Does anyone know of any setting or compilation trick that will
>>> diminish the flicker? I know that everything is double buffered
>>> on X11 and Windows but what about embedded platforms on the 
>>> framebuffer?
>> Maybe I should also indicate that the framebuffer runs on a TV set 
>> via a SVideo connection.
> 
> That's the tiny little bit of information which might make the
> difference ;)

Yeah I guessed that much :-)

> I am not a TV technician, but usually TVs have a refresh rate of 50
> Hz interlaced.

Yep, that's 50Hz for PAL and 60Hz for NTSC (actually half of that 
interlaced).

> So depending with which framerate the framebuffer is
> updated (e.g. 60 Hz) you'll likely to see effects to which you are
> referring to as "flicker". Because a typical TV (not LCD, but CRT -
> http://en.wikipedia.org/wiki/Cathode_ray_tube) draws "line by line",
> and if you refresh the graphic card memory while the "cathode ray" is
> in the middle of "updating the TV screen" you'll notice this as
> flicker or similar visual ugly "artefacts".
> 
> Off course my assumption would only make sense if you observe the
> same flicker effect with other (non-Qt) applications with
> update-intensive (="lots of moving stuff") graphic output. When you
> see a "static" image (e.g. when you don't move any windows around on
> the screen, for instance), the flicker-effect is off course not so
> obvious - the screen always "paints" the same image.

Well, yes and no: when I launch the svgviewer or the imageviewer demos 
for example, the image display is stable but the menubar and window 
decoration is not. It seems that the dialogs "tremble". I don't know if 
they move a tiny bit back and forth at each redraw or if it is just that 
they are drawn only once over two refresh periods. Just for the record, 
this 'flicker' happens with static windows and controls, I am not moving 
anything.

> Some graphic hardware drivers have an option like "Synchronise memory
> refresh with display refresh rate" (which makes only a visible
> difference with CRT monitors, I guess): it doesn't refresh the
> graphic card memory, until the cathode ray has "jumped back" to
> "top-left", where it starts again to draw line by line... (which
> takes some time, and in this time the graphic card memory is
> updated).
> 
> Note that with modern LCD displays you won't notice any flicker,
> because they don't have a "cathode ray" which draws each line after
> another, just like with a good old CRT monitor (and I assume your TV
> falls into this category).

Well, my pretty good LCD screen has an S-Video input connector so I am 
able to test the demo both in the CRT and LCD monitors. Unfortunately, 
the same 'flicker' effect happens on the LCD; identically, the central 
image is stable but the window decoration and the dialogs are not.

> But generally it is pretty useless to
> refresh the graphic card memory faster than your screen's refresh
> rate - Unless you want to prove the power of your Giga-Game-Blaster
> 3D card... ;)
> 
> So my guess is that with your specific embedded device you'll have to
> find a way to convince the framebuffer to synchronise with your TV -
> since the framebuffer can't possibly know when the TV's cathode ray
> "jumps back" (this information is not transmitted over a plain SVideo
> cable ;) I am not even sure if this is possible. At least try to set
> the same refresh rate as the TV has (50 Hz or so).

I'll digg a bit more into that, but I am no very confident. The Davinci 
evaluation board comes with a small demo with some buttons and there is 
no 'flicker' here. I suspect they draw onto the framebuffer directly.

> 
> Cheers, Oliver -- Oliver Knoll

Thanks a lot for your insight Olivier.

Abdel.