[Development] Scenegraph Triple Buffering

[Dietrich.Gossen at conti-engineering.com]

Hi,

I set the Samples to 1.
format.setSamples(1);

The rotation looks better now, but still not perfect.
I am not sure how to interpret the output of QML_RENDER_TIMING=1

This is how the output looks like (during rotation):



Do you know any other performance improvements, regarding QML?

Thanks.
Dietrich



Von:    <gunnar.sletta at nokia.com>
An:     <Dietrich.Gossen at conti-engineering.com>
Kopie:  <development at qt-project.org>
Datum:  28.06.2012 13:49
Betreff:        Re: [Development] Scenegraph Triple Buffering




On Jun 28, 2012, at 12:57 PM, ext Dietrich.Gossen at conti-engineering.com 
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:        <gunnar.sletta at nokia.com> 
> An:        <Dietrich.Gossen at conti-engineering.com> 
> Kopie:        <development at qt-project.org> 
> Datum:        28.06.2012 11:39 
> Betreff:        Re: [Development] Scenegraph Triple Buffering 
> 
> 
> 
> 
> On Jun 28, 2012, at 10:58 AM, ext Dietrich.Gossen at conti-engineering.com 
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
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120703/afa931cb/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: frametime.txt
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120703/afa931cb/attachment.txt>