[Development] Late API addition in QScreen for 5.0

Samuel Rødal samuel.rodal at nokia.com
Fri May 4 18:16:09 CEST 2012

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.

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:


More information about the Development mailing list