← Back to branch summary

~oif-team/ubuntu/natty/qt4-x11/xi2.1

« back to all changes in this revision

Viewing changes to doc/src/emb-performance.qdoc

  • Committer: Bazaar Package Importer
  • Author(s): Alessandro Ghersi
  • Date: 2009-11-02 18:30:08 UTC
  • mfrom: (1.2.2 upstream)
  • mto: (15.2.5 experimental)
  • mto: This revision was merged to the branch mainline in revision 88.
  • Revision ID: james.westby@ubuntu.com-20091102183008-b6a4gcs128mvfb3m
Tags: upstream-4.6.0~beta1
Import upstream version 4.6.0~beta1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/emb-performance.qdoc
1
 
/****************************************************************************
2
 
**
3
 
** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
4
 
** Contact: Nokia Corporation (qt-info@nokia.com)
5
 
**
6
 
** This file is part of the documentation of the Qt Toolkit.
7
 
**
8
 
** $QT_BEGIN_LICENSE:LGPL$
9
 
** Commercial Usage
10
 
** Licensees holding valid Qt Commercial licenses may use this file in
11
 
** accordance with the Qt Commercial License Agreement provided with the
12
 
** Software or, alternatively, in accordance with the terms contained in
13
 
** a written agreement between you and Nokia.
14
 
**
15
 
** GNU Lesser General Public License Usage
16
 
** Alternatively, this file may be used under the terms of the GNU Lesser
17
 
** General Public License version 2.1 as published by the Free Software
18
 
** Foundation and appearing in the file LICENSE.LGPL included in the
19
 
** packaging of this file.  Please review the following information to
20
 
** ensure the GNU Lesser General Public License version 2.1 requirements
21
 
** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
22
 
**
23
 
** In addition, as a special exception, Nokia gives you certain
24
 
** additional rights. These rights are described in the Nokia Qt LGPL
25
 
** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
26
 
** package.
27
 
**
28
 
** GNU General Public License Usage
29
 
** Alternatively, this file may be used under the terms of the GNU
30
 
** General Public License version 3.0 as published by the Free Software
31
 
** Foundation and appearing in the file LICENSE.GPL included in the
32
 
** packaging of this file.  Please review the following information to
33
 
** ensure the GNU General Public License version 3.0 requirements will be
34
 
** met: http://www.gnu.org/copyleft/gpl.html.
35
 
**
36
 
** If you are unsure which license is appropriate for your use, please
37
 
** contact the sales department at http://www.qtsoftware.com/contact.
38
 
** $QT_END_LICENSE$
39
 
**
40
 
****************************************************************************/
41
 
 
42
 
/*!
43
 
    \page qt-performance.html
44
 
    \title Qt Performance Tuning
45
 
    \ingroup qtce
46
 
    \ingroup qt-embedded-linux
47
 
    \brief Ways to improve performance on embedded platforms.
48
 
 
49
 
    When building embedded applications on low-powered devices,
50
 
    \l{Qt for Windows CE} and \l{Qt for Embedded Linux} provide
51
 
    a number of options that reduce the memory and/or CPU requirements
52
 
    by making various trade-offs. These options range from variations
53
 
    in programming style, to linking and memory allocation.
54
 
 
55
 
    Note that the most direct way of saving resources, is to avoid compiling
56
 
    in features that are not required. See the \l{Fine-Tuning Features in Qt}
57
 
    {fine tuning features} documentation for details.
58
 
 
59
 
    \tableofcontents
60
 
 
61
 
    \section1 Programming Style
62
 
 
63
 
    Rather than creating dialogs and widgets every time they are
64
 
    needed, and delete them when they are no longer required, create
65
 
    them once and use the QWidget::hide() and QWidget::show()
66
 
    functions whenever appropriate. To avoid a slow startup of the
67
 
    application, delay the creation of dialogs and widgets until they
68
 
    are requested. All this will improve the CPU performance, it
69
 
    requires a little more memory, but will be much faster.
70
 
 
71
 
    \section1 Static vs. Dynamic Linking
72
 
 
73
 
    A lot of CPU and memory is used by the ELF (Executable and Linking
74
 
    Format) linking process. Significant savings can be achieved by
75
 
    using a static build of the application suite; rather than having
76
 
    a collection of executables which link dynamically to Qt's
77
 
    libraries, all the applications is built into into a single
78
 
    executable which is statically linked to Qt's libraries.
79
 
 
80
 
    This improves the start-up time and reduces memory usage at the
81
 
    expense of flexibility (to add a new application, you must
82
 
    recompile the single executable) and robustness (if one
83
 
    application has a bug, it might harm other applications).
84
 
 
85
 
    \table 100%
86
 
    \row
87
 
    \o \bold {Creating a Static Build}
88
 
 
89
 
    To compile Qt as a static library, use the \c -static option when
90
 
    running configure:
91
 
 
92
 
    \snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 0
93
 
 
94
 
    To build the application suite as an all-in-one application,
95
 
    design each application as a stand-alone widget (or set of
96
 
    widgets) with only minimal code in the \c main() function. Then,
97
 
    write an application that provides a means of switching between
98
 
    the applications.  The \l Qt Extended platform is an example using this
99
 
    approach: It can be built either as a set of dynamically linked
100
 
    executables, or as a single static application.
101
 
 
102
 
    Note that the application still should link dynamically against
103
 
    the standard C library and any other libraries which might be used
104
 
    by other applications on the target device.
105
 
 
106
 
    \endtable
107
 
 
108
 
    When installing end-user applications, this approach may not be an
109
 
    option, but when building a single application suite for a device
110
 
    with limited CPU power and memory, this option could be very
111
 
    beneficial.
112
 
 
113
 
    \section1 Alternative Memory Allocation
114
 
 
115
 
    The libraries shipped with some C++ compilers on some platforms
116
 
    have poor performance in the built-in "new" and "delete"
117
 
    operators. Improved memory allocation and performance may be
118
 
    gained by re-implementing these functions:
119
 
 
120
 
    \snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 1
121
 
 
122
 
    The example above shows the necessary code to switch to the plain
123
 
    C memory allocators.
124
 
 
125
 
    \section1 Bypassing the Backing Store
126
 
 
127
 
    When rendering, Qt uses the concept of a backing store; i.e., a
128
 
    paint buffer, to reduce flicker and to support graphics operations
129
 
    such as blending.
130
 
 
131
 
    The default behavior is for each client to render
132
 
    its widgets into memory while the server is responsible for
133
 
    putting the contents of the memory onto the screen. But when the
134
 
    hardware is known and well defined, as is often the case with
135
 
    software for embedded devices, it might be useful to bypass the
136
 
    backing store, allowing the clients to manipulate the underlying
137
 
    hardware directly.
138
 
    \if defined(qtce)
139
 
    This is achieved by setting the Qt::WA_PaintOnScreen window attribute
140
 
    for each widget.
141
 
    \else
142
 
 
143
 
    There are two approaches to direct painting: The first approach is
144
 
    to set the Qt::WA_PaintOnScreen window attribute for each widget,
145
 
    the other is to use the QDirectPainter class to reserve a region
146
 
    of the framebuffer.
147
 
      For more information, see the
148
 
      \l{Qt for Embedded Linux Architecture#Direct Painting}{direct painting}
149
 
      section of the \l{Qt for Embedded Linux Architecture}{architecture}
150
 
      documentation.
151
 
    \endif
152
 
*/