On Jun 28, 2012, at 12:57 PM, ext [email protected] wrote:
> The used hardware is: i.MX6 Sabrelite (with powerful gpu from vivante) > Used Qt-Version: 5.0.0 Alpha with eglfs plugin > > The Qt Application contains scaling, rotations and moving of images. The > application is a comination of QML and C++. > I am searching for the bottleneck. > > The hellogl_es2 example is running with 75 fps (with vsync on). But > hellogl_es2 is not using QML. It also doesn't try to enable multisampling, QQuickView does. Depending on the hardware this can have significant impact on performance. The way to change it right now would be to change the requested format we return in src/quick/scenegraph/qsgcontext.cpp in the function QSGContext::defaultSurfaceFormat(). If you do not want to change the source code, of Qt it is possible to write an adaptation plugin for the scene graph to request (among other things) a different surface format, but to just check the impact, it is not worth it :) > My first idea was to enable triple buffering, and compare the result to > double buffering with vsync. The threaded renderer, which you should already hit by using the EGLFS plugin, does animations and rendering/swap in different threads, so the overall hit of doublebuffering with a potential wait-for-swap is already greatly reduced as the next frame can be prepared while the render thread is waiting for swap. You can try the environment variable QML_CANVAS_TIMING=1 which prints out which part of the render loop is taking up time. cheers, Gunnar > Best regards > > Dietrich > > > > Von: <[email protected]> > An: <[email protected]> > Kopie: <[email protected]> > Datum: 28.06.2012 11:39 > Betreff: Re: [Development] Scenegraph Triple Buffering > > > > > On Jun 28, 2012, at 10:58 AM, ext [email protected] wrote: > > > Hi, > > > > There is some Qt 5.0 documentation available about > > QSurfaceFormat::SwapBehavior. There is a constant called > > QSurfaceFormat::TripleBuffer . > > Is this feature already implemented and tested in Qt 5 Alpha? > > This parameter is picked up by the platform's OpenGL implementation if > anything, but none of our desktop backends currently make use of this as the > buffering policy is typically decided for us by the system. This is mostly a > hint to be picked up by EGL implementations where applicable. > > > The reason I am asking, is because we are facing the typical issues with > > Double buffering and vsync turned on. > > The fps drops to 30. > > What system / setup is this and what are you trying to draw? There is no > reason why double buffering combined with vsync should result in 30FPS, > unless each frame takes in the range 17-33ms to draw. Does this happen also > for a very simple scene? > > cheers, > Gunnar > > > > Thanks > > > > Best regards > > > > Dietrich Gossen > > _______________________________________________ > > Development mailing list > > [email protected] > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
