On Fri, May 4, 2012 at 9:16 AM, Samuel Rødal <[email protected]> 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 <[email protected]> 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) Girish _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
