diff options
author | Gunnar Sletta <gunnar.sletta@digia.com> | 2013-05-22 13:09:29 +0200 |
---|---|---|
committer | The Qt Project <gerrit-noreply@qt-project.org> | 2013-05-31 15:22:48 +0200 |
commit | 6b1f06b1c4a1a562a1778c3cb690f887d8c6f8c6 (patch) | |
tree | 9fc89c5538c936a16ba00d0ed6283ab556d04693 | |
parent | 81c5d0053e0c1bebbfd45a46d44c744e4576b543 (diff) |
Make performance guide slightly more accurate
Change-Id: I5c7416d4e4a67f8c4c8490109876ae45be59652f
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
-rw-r--r-- | doc/src/qmlapp/performance.qdoc | 35 |
1 files changed, 18 insertions, 17 deletions
diff --git a/doc/src/qmlapp/performance.qdoc b/doc/src/qmlapp/performance.qdoc index d87f88124..b8fb1c389 100644 --- a/doc/src/qmlapp/performance.qdoc +++ b/doc/src/qmlapp/performance.qdoc @@ -777,17 +777,6 @@ It should be noted that a particle system can be disabled when not in use See the \l{Particle System Performance Guide} for more in-depth information. -\section2 Shaders - -Shaders written in GLSL allow for complex transformations and visual effects to be written, -however they should be used with care. Using a ShaderEffectSource causes a scene to -prerendered into an FBO before it can be drawn. This extra overhead is quite expensive. - -A ShaderEffect element can imply a ShaderEffectSource (and the indirect rendering costs -associated with that) and also involves uploading a vertex and fragment shader program -(which is then compiled into a GLSL shader). Each fragment shader runs once for every -pixel of the scene, and so these should be kept as simple as possible. - \section1 Controlling Element Lifetime By partitioning an application into simple, modular components, each contained in a single @@ -867,14 +856,26 @@ activated), should have their "visible" property set to \c false, in order to av cost of drawing them (although as previously explained, they will still incur the cost of any animations or bindings evaluation since they are still active). -\section2 Manual Layouts +\section2 Translucent vs Opaque -The scene graph renderer is able to batch up certain operations to minimize the number of -OpenGL state changes required. However, this optimization is only possible for the -built-in layout elements provided by \c {QtQuick 2.0}, and cannot be applied to manual layouts. +Opaque content is generally a lot faster to draw than translucent. The reason being +that translucent content needs blending and that the renderer can potentially optimize +opaque content better. -Therefore, application developers should use the Row, Column, Grid, GridView, and ListView -elements instead of manual layouts wherever possible. +An image with one translucent pixel is treated as fully translucent, even though it +is mostly opaque. The same is true for an \l BorderImage with transparent edges. + +\section2 Shaders + +The \l ShaderEffect type makes it possible to place GLSL code inline in a Qt Quick application with +very little overhead. However, it is important to realize that the fragment program needs to run +for every pixel in the rendered shape. When deploying to low-end hardware and the shader +is covering a large amount of pixels, one should keep the fragment shader to a few instructions +to avoid poor performance. + +Shaders written in GLSL allow for complex transformations and visual effects to be written, +however they should be used with care. Using a \l ShaderEffectSource causes a scene to be +prerendered into an FBO before it can be drawn. This extra overhead can be quite expensive. \section1 Memory Allocation And Collection |