[Development] Late API addition in QScreen for 5.0

Girish Ramakrishnan girish at forwardbias.in
Fri May 4 18:43:34 CEST 2012

On Fri, May 4, 2012 at 9:16 AM, Samuel Rødal <samuel.rodal at nokia.com> wrote:
> On 05/04/2012 05:55 PM, ext Girish Ramakrishnan wrote:
>> Hi,
>> On Fri, May 4, 2012 at 7:22 AM, Samuel Rødal <samuel.rodal at nokia.com> wrote:
>>> On 05/04/2012 04:03 PM, ext Christoph Feck wrote:
>>>> On Friday 04 May 2012 13:37:04 Samuel Rødal wrote:
>>>>> Hello,
>>>>> to be able to achieve smooth animations in QML 2, the animations
>>>>> should ideally use a fixed timestep, and not a timer which might
>>>>> have inaccuracies depending on the platform and won't give fully
>>>>> smooth results.
>>>> Does OpenGL 2 have API to drive animations by vertical blanking
>>>> interrupts instead of using a timer? From my experience with movie
>>>> players, you always get tearing or stuttering, if the frame rate of
>>>> the display is not a 100% exact multiple of that of the animation or
>>>> the video.
>>> No, there's not any API in OpenGL for that. It's all very windowing
>>> system and graphics driver dependent.
>>> I believe Mac OS X doesn't have any tearing, correct me if I'm wrong though.
>>> On Linux, it's all up to the graphics driver in my experience. With the
>>> binary Nvidia driver the only reliable way I've seen of enabling vsync
>>> has been to do "export __GL_SYNC_TO_VBLANK=1" before launching an
>>> application. AMD's Catalyst control panel now has an option called "Tear
>>> Free Desktop" which is supposed to also sync rendering, but when I've
>>> tried it I've still gotten tearing, just now it's in the same location
>>> each frame, which looks even worse.
>> The advice above needs to make it to the release notes since everyone
>> is going to face this problem. On X11 (with xcb), we were seeing high
>> cpu usage and poor performance with nvidia cards. After Samuel
>> enlightened us about the env variable, QML2 apps started working very
>> smoothly. (Donald, want to add more to this?)
> There is some risk involved though; an application with multiple windows
> each being rendered to with OpenGL in a single thread will end up
> achieving a max framerate of screen_refresh_rate /
> number_of_animating_windows, due to swapBuffers blocking. Since it's not
> a panacea, it might be too dangerous to enable it unconditionally.

:( I guess the solution is if we can somehow get one render thread per
window (which Samuel told me on irc is not safe with current design).

> We also need to consider what to do with the threading and buffer
> queuing capabilities in the platform integration, that make a big
> difference in the animation quality. I've made this change that adds an
> environment variable to enforce the threaded renderer, to at least give
> some degree of control over it without having to recompile Qt:
> https://codereview.qt-project.org/#change,25271

This change is indeed very useful. For the raspberry pi, amlogic
8726-M, turning on BufferedQueing has made a big difference to
performance. It would be great to have this somehow be determined
programmatically. If that's not possible, can we add a
qmlscene-launcher script to qtdeclarative that basically checks the
graphics driver and turns on/off these environment variables? (I can
provide a change, if we agree)


More information about the Development mailing list