Comment 15 for bug 981199

Yes, we can save time when using a single OpenGL context. This will also help to use the V-sync facilitys of open GL.

I have tried to nail down this bug and it turns out to be more then one overlapping issues.

1) refresh() is not called reliable in time, sometimes we miss a v-Sync slot.
** the best results might be achievable if we are V-synced by a kind of high prioriti multi media timer.
** I have played arround with this issue but wit no success.
** I Think this is caused by other events processed from the GUI Thread. Since we have only one GUI Thread they will not yield for the refesch() event.
** I have tried to use a dedicated open GL Thread but without a better result.
2) we have to be sure that the Pixel Buffers are swaped in time.
** I have moved the postRender() call to the beginning of refresh()
** and I have changed it in a way that QT swaps emediatly and not when it thinks its best.
3) we have to be sure, that the new frame is rendered in time
** I am not sure how to read the results from Jus. Is CGLFlushDrawable called for every frame?
** Does it take longer in certain situations so we miss finish rendering in time?
4) we have to be sure that the audio is in sync with the video.
** this is not the case in trunk version
** I have prepared a solution with a VisaulPlayPosition Class that is able to sync them better.

I think 2-3 might be be solved in my current lp:~daschuer/mixxx/daschuers_trunk but I still have not a significant improvement.
I am still looking for a good solution for 1! Any Ideas?

By the way:
We may also save time if we pre-draw the entire waveform and diplay only the needed part or only repaint the frams that are moving in the view.