summaryrefslogtreecommitdiffstats
path: root/doc/src/emb-performance.qdoc
diff options
context:
space:
mode:
Diffstat (limited to 'doc/src/emb-performance.qdoc')
-rw-r--r--doc/src/emb-performance.qdoc152
1 files changed, 152 insertions, 0 deletions
diff --git a/doc/src/emb-performance.qdoc b/doc/src/emb-performance.qdoc
new file mode 100644
index 0000000..79edf34
--- /dev/null
+++ b/doc/src/emb-performance.qdoc
@@ -0,0 +1,152 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Qt Software Information (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at qt-sales@nokia.com.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+ \page qt-performance.html
+ \title Qt Performance Tuning
+ \ingroup qtce
+ \ingroup qt-embedded-linux
+ \brief Ways to improve performance on embedded platforms.
+
+ When building embedded applications on low-powered devices,
+ \l{Qt for Windows CE} and \l{Qt for Embedded Linux} provide
+ a number of options that reduce the memory and/or CPU requirements
+ by making various trade-offs. These options range from variations
+ in programming style, to linking and memory allocation.
+
+ Note that the most direct way of saving resources, is to avoid compiling
+ in features that are not required. See the \l{Fine-Tuning Features in Qt}
+ {fine tuning features} documentation for details.
+
+ \tableofcontents
+
+ \section1 Programming Style
+
+ Rather than creating dialogs and widgets every time they are
+ needed, and delete them when they are no longer required, create
+ them once and use the QWidget::hide() and QWidget::show()
+ functions whenever appropriate. To avoid a slow startup of the
+ application, delay the creation of dialogs and widgets until they
+ are requested. All this will improve the CPU performance, it
+ requires a little more memory, but will be much faster.
+
+ \section1 Static vs. Dynamic Linking
+
+ A lot of CPU and memory is used by the ELF (Executable and Linking
+ Format) linking process. Significant savings can be achieved by
+ using a static build of the application suite; rather than having
+ a collection of executables which link dynamically to Qt's
+ libraries, all the applications is built into into a single
+ executable which is statically linked to Qt's libraries.
+
+ This improves the start-up time and reduces memory usage at the
+ expense of flexibility (to add a new application, you must
+ recompile the single executable) and robustness (if one
+ application has a bug, it might harm other applications).
+
+ \table 100%
+ \row
+ \o \bold {Creating a Static Build}
+
+ To compile Qt as a static library, use the \c -static option when
+ running configure:
+
+ \snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 0
+
+ To build the application suite as an all-in-one application,
+ design each application as a stand-alone widget (or set of
+ widgets) with only minimal code in the \c main() function. Then,
+ write an application that provides a means of switching between
+ the applications. The \l Qt Extended platform is an example using this
+ approach: It can be built either as a set of dynamically linked
+ executables, or as a single static application.
+
+ Note that the application still should link dynamically against
+ the standard C library and any other libraries which might be used
+ by other applications on the target device.
+
+ \endtable
+
+ When installing end-user applications, this approach may not be an
+ option, but when building a single application suite for a device
+ with limited CPU power and memory, this option could be very
+ beneficial.
+
+ \section1 Alternative Memory Allocation
+
+ The libraries shipped with some C++ compilers on some platforms
+ have poor performance in the built-in "new" and "delete"
+ operators. Improved memory allocation and performance may be
+ gained by re-implementing these functions:
+
+ \snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 1
+
+ The example above shows the necessary code to switch to the plain
+ C memory allocators.
+
+ \section1 Bypassing the Backing Store
+
+ When rendering, Qt uses the concept of a backing store; i.e., a
+ paint buffer, to reduce flicker and to support graphics operations
+ such as blending.
+
+ The default behavior is for each client to render
+ its widgets into memory while the server is responsible for
+ putting the contents of the memory onto the screen. But when the
+ hardware is known and well defined, as is often the case with
+ software for embedded devices, it might be useful to bypass the
+ backing store, allowing the clients to manipulate the underlying
+ hardware directly.
+ \if defined(qtce)
+ This is achieved by setting the Qt::WA_PaintOnScreen window attribute
+ for each widget.
+ \else
+
+ There are two approaches to direct painting: The first approach is
+ to set the Qt::WA_PaintOnScreen window attribute for each widget,
+ the other is to use the QDirectPainter class to reserve a region
+ of the framebuffer.
+ For more information, see the
+ \l{Qt for Embedded Linux Architecture#Direct Painting}{direct painting}
+ section of the \l{Qt for Embedded Linux Architecture}{architecture}
+ documentation.
+ \endif
+*/