Flickering / framebuffer / OpenGL issues

[OwenW]

Hi all,

I'm starting this thread to collect information about flickering and other visual issues.   We can share tips, etc as to how to resolve it.

My experience: sometimes I get no flickering, other times it flickers a lot.  The latest 0.6.1 has an option to disable 'video optimisation' in the new Setup > Preferences menu - this helps a lot but has its own smaller issue - the text (e.g. 'Accuracy') and clef,etc dissappears for a quarter second every bar.  This is very minor, and I can certainly live with it.

I'm on Ubuntu 8.04 with ati onboard graphics and there are quite a few forums discussions talking about flickering problems with OpenGL apps and my ati drivers.  One suggestion that keeps cropping up is to switch off compiz, however I'm not using this at the moment.

I've dug a little bit into the code (my c is poor but I program other languages) and can see that the drawing pane uses a QGLWidget - this has double buffering on by default so I'm surprised to see only parts of the screen rendered as the code should be working on the back buffer and swapping only when the frame has been modified completely.  

http://doc.trolltech.com/3.3/qglformat.html#setDoubleBuffer

Perhaps Louis can shed some light.  

[Louis B.]

I am busy for the next few days and so I'll answer in detail after then.

In the mean time it would be useful if every one could list their experiences + graphic card/chip + os.

Louis

[Louis B.]

Ok I am looking at this problem now, 2 questions.

Please can you try other open gl programs eg Planet Penguin Racer, Frets on fire, Stellarium, all the GL screen savers. Do these programs also have problems or is just PB that you have problems with. If you start PB with -q which removes all the text does anything flicker now?

Is it Just the text? If so exactly which text flickers. (you the text flickers but the treble and base clef are not text).

If you register for the forum I can contact you even if you are not regularly checking this forum.

Out of interest what languages can you program in.

Louis

[Louis B.]

try changing Draw.h:46 REDRAW_COUNT to 1000 just to see if that makes any difference?

[OwenW]

I've registered to nabble now.

Sorry I haven't replied sooner, too busy playing planet penguin racer (ahem).  No problems with penguin racer, graphics and text look very smooth.  Same with Stellarium, no flickering (text or otherwise).

I've tried with the -q flag.  This flag doesn't quite do what you say (at least not on my machine) - I can still see the text (accuracy, song, bar), the only thing that is missing is the time signature text (e.g. 4/4).

You asked me what flickers...

Here is a detailed description

[WHEN VIDEO OPTIMISATION IS OFF]
Nothing flickers until I press play.  The 'flickering' is very predictable, it flickers only on the first beat of each bar.  I suspect this is when you ask get the app to do a complete redraw or something.  What flickers? Just the text (Accuracy, song, bar) and the time signature.  Everything else (clef and flats/sharps, notes, bars, verticals, etc) all do *not* flicker at all.  It's not really a 'flicker' as such - basically the text and time signature disappear for half a beat and, as I said before, this always happens on the first beat of each bar (i.e. the first thin vertical after a thick vertical).

[WHEN VIDEO OPTIMISATION IS ON]
Often all is good (no flickering) - but occasionally I get rapid flickering on (accuracy, song, bar) but everything else is rock solid (including time signature).  Why would the time signature not flicker when other text does? Is it getting printed out differently?

I mainly program in Java but sometimes do C# and scripting language.  I did C about 15 years ago as an Engineering module at University.

[OwenW]

I've changed REDRAW_COUNT to 1000.

I see no change when "VIDEO OPTIMISATION=OFF".  i.e. text still disappears once per bar.

I do notice a change when "VIDEO OPTIMISATION=ON".  It now behaves identically to "VIDEO OPTIMISATION=OFF" i.e. it no longer flickers but text disappears on first beat of each bar.

[OwenW]

A couple more observations.

[I've changed REDRAW_COUNT back to 2]

When video optimisation is off.  I stated that text dissapears on first beat of bar.  The text also disappears (in follow you mode) each time I hit a *correct* note on my computer keyboard, but does not disappear if I hit the *wrong* note.  In play-along mode the text disappears after hitting any note.

Finally the text also disappears indefinitely (doesn't come back) at the start of the last bar.  When I say last bar, I mean the last bar that has notes on it.  Hence text will disappear before the last note has played.  This happens regardless of video optimsation mode or redraw count.

[Louis B.]

Hi Owen,

Thanks for your detailed posts.

It is now looking like the text problem is a bug in the QT4 renderText. I compiled the latest stellarium-0.10.1 from source and got similar problems. in particular missing chars. (See this post "problem with fonts in Stellarium 0.10.1" http://sourceforge.net/forum/forum.php?thread_id=2978794&forum_id=278769, but I think the problem may be in QT rather than the video driver)


 I found a very crude work around by adding these line in GLView. (you may need to do an svn update)

    if (!Cfg::quickStart)
    {
        renderText(10,10,"~", m_timeRatingFont); //fixme this is a work around for a QT bug.
        renderText(10,10,"~", m_timeSigFont); //fixme this is a work around for a QT bug.
    }

The "~" char would be missing from any text (if you changed "~" to "B" then the B of Bar would be missing). I now get the flickering you describe for each bar but only with the video optimisation turned on and only with the time signature text. It would be useful to try PB with the latest version of Qt in case there is already a bug fix for this problem. We really should report this as a bug to qt since I have seen exactly the same problem in stellarium-0.10.1.
 
There is an alternative and that is to manually draw the text and not use qt renderText as per the stroke.c example code available on this page http://www.sgi.com/products/software/opengl/examples/redbook/


The video optimisation is something that I have implemented myself and it works by only redrawing just the scrolling area that is moving and not clearing and redrawing the whole screen every frame. Unfortunately it seems that some gl graphic drivers do not like it if you do not redraw the whole screen every frame and so I added the option to disable it. I have not found an example/tutorial on how to do a partial screen redraw so I may not be doing it correctly.



At first sight it might appear quite easy to scroll the notes across the page but in reality it is quite difficult which is probably explains why most other (all other?) sequencers don't do it. Instead they keep the notes still and move a marker across the page.

The first problem is in order to read the notes from the page you don't want see any flickering when scrolling. So to try and get the notes to move smoothly I have a _very_ high frame rate. currently it is 12msec or 83Hz. (You can try playing with this value, search for "m_timer.start" in GlView.cpp. What value works best for you?).

At the moment the midi update rate is tied to the graphics refresh rate but ideally the midi update rate should go much faster at once every 1msec.

If you put in a lower video frame rate then the "opengl tearing problem" becomes more obvious. The tearing problem is much worse because we are scrolling across the screen. Programs like Frets on Fire scroll down the screen and so the tearing problem may not be so noticeable. Can you see any tearing on TuxRacer?

Incidentally the green on black colours is to try and use they eyes ability to persist a flash of light on the retina. If I had used black notes on a white background then it would be the white light of the background that would persist in the retina causing the black notes to blur when they are moved.


The problem with a high frame rate is that pb then starts to eat up CPU time, this bad news for a real-time app. I have tried hard to use as little of the CPU time as possible so that I don't use up all of my allocated CPU time. I have not given PB any special real time status/priority as I do not know how to do this.  Does any body know how to do this?

THE FIX for the tearing problem is to use QGLFormat::setSwapInterval() with a value of 0, but unfortunately I could not get this to work.(start pb with the -X2 to enable this experimental code). If someone can get this work then this would also mean we could use a more sensible video frame rate.

Also see this very old post about the tearing problem

http://lists.trolltech.com/qt-interest/2006-04/msg00313.html

L o u i s

[OwenW]

On linux you could use 'nice' or 'renice' to give PianoBooster greater priority.  

e.g.  sudo nice -n-5 ./pianobooster

Careful as this runs as pianobooster as root.  If you use 'top' command you can now see the process running as NI=-5 which means it is less nice (more greedy) than most user processes.

On Windows you can do something similar in task manager, right click the process and there is an option to change process priority.  

Both of these aren't great as you don't really want end users manually doing this sort of thing.

I've sent a patch to your sourceforge email which solves my vanishing text issue.

After your changes and my patch, I'm not currently seeing flickering with video optimisation off or on.  Although I think I saw a little bit of flickering (optimisation on) when I first tried the app.  Lets say it seems to be happening less often, if at all.

[OwenW]

What is it about "QGLFormat::setSwapInterval()" that doesn't work?  I've set the value to 0, 1 and 100 and it at least 'sets' OK (and I can read the value back using QGLFormat::defaultFormat().swapInterval();).

Is it that whilst the value can be set, it doesn't actually do anything?  I guess a bit of fps logging might show whether it does anything...

[Louis B.]

I put in a value of 100 to test it. it should reduce the frame rate to vsync rate * 100 ( about 2 seconds for each frame). Do you see any tearing? if it works the tearing should disappear altogether.

[OwenW]

I see a few tears.  I guess its not syncing.

2009/3/18 Louis B. (via Nabble) <[hidden email]>

I put in a value of 100 to test it. it should reduce the frame rate to vsync rate * 100 ( about 2 seconds for each frame). Do you see any tearing? if it works the tearing should disappear altogether.

---

This email is a reply to your post @ http://n2.nabble.com/Flickering---framebuffer---OpenGL-issues-tp2464398p2500320.html

You can reply by email or by visting the link above.