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