1 files changed, 152 insertions, 0 deletions
diff --git a/doc/src/platforms/emb-performance.qdoc b/doc/src/platforms/emb-performance.qdoc
new file mode 100644
index 0000000..9bc373b
--- /dev/null
+++ b/doc/src/platforms/emb-performance.qdoc
@@ -0,0 +1,152 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Nokia Corporation (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 http://qt.nokia.com/contact.
+** $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
+*/