| 1 | /****************************************************************************
|
|---|
| 2 | **
|
|---|
| 3 | ** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
|
|---|
| 4 | ** Contact: Qt Software Information (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 qt-sales@nokia.com.
|
|---|
| 38 | ** $QT_END_LICENSE$
|
|---|
| 39 | **
|
|---|
| 40 | ****************************************************************************/
|
|---|
| 41 |
|
|---|
| 42 | /*!
|
|---|
| 43 | \example qws/ahigl
|
|---|
| 44 | \title OpenGL for Embedded Systems Example
|
|---|
| 45 |
|
|---|
| 46 | \section1 Introduction
|
|---|
| 47 |
|
|---|
| 48 | This example demonstrates how you can use OpenGL for Embedded
|
|---|
| 49 | Systems (ES) in your own screen driver and \l{add your graphics
|
|---|
| 50 | driver to Qt for Embedded Linux}. In \l{Qt for Embedded Linux},
|
|---|
| 51 | painting is done in software, normally performed in two steps:
|
|---|
| 52 | First, each client renders its windows onto its window surface in
|
|---|
| 53 | memory using a paint engine. Then the server uses the screen
|
|---|
| 54 | driver to compose the window surface images and copy the
|
|---|
| 55 | composition to the screen. (See the \l{Qt for Embedded Linux
|
|---|
| 56 | Architecture} documentation for details.)
|
|---|
| 57 |
|
|---|
| 58 | This example is not for the novice. It assumes the reader is
|
|---|
| 59 | familiar with both OpenGL and the screen driver framework
|
|---|
| 60 | demonstrated in the \l {Accelerated Graphics Driver Example}.
|
|---|
| 61 |
|
|---|
| 62 | An OpenGL screen driver for Qt for Embedded Linux can use OpenGL ES
|
|---|
| 63 | in three ways. First, the \l{QWSServer}{Qt for Embedded Linux server}
|
|---|
| 64 | can use the driver to compose multiple window images and then show the
|
|---|
| 65 | composition on the screen. Second, clients can use the driver to
|
|---|
| 66 | accelerate OpenGL painting operations using the QOpenGLPaintEngine
|
|---|
| 67 | class. Finally, clients can use the driver to do OpenGL operations
|
|---|
| 68 | with instances of the QGLWidget class. This example implements all
|
|---|
| 69 | three cases.
|
|---|
| 70 |
|
|---|
| 71 | The example uses an implementation of OpenGL ES from
|
|---|
| 72 | \l {http://ati.amd.com}{ATI} for the
|
|---|
| 73 | \l {http://ati.amd.com/products/imageon238x/}{Imageon 2380}. The
|
|---|
| 74 | OpenGL include files gl.h and egl.h must be installed to compile
|
|---|
| 75 | the example, and the OpenGL and EGL libraries must be installed
|
|---|
| 76 | for linking. If your target device is different, you must install
|
|---|
| 77 | the include files and libraries for that device, and you also
|
|---|
| 78 | might need to modify the example source code, if any API signatures
|
|---|
| 79 | in your EGL library differ from the ones used here.
|
|---|
| 80 |
|
|---|
| 81 | After compiling and linking the example source, install the
|
|---|
| 82 | screen driver plugin with the command \c {make install}. To
|
|---|
| 83 | start an application that uses the plugin, you can either set the
|
|---|
| 84 | environment variable \l QWS_DISPLAY and then start the
|
|---|
| 85 | application, or just start the application with the \c -display
|
|---|
| 86 | switch, as follows:
|
|---|
| 87 |
|
|---|
| 88 | \snippet doc/src/snippets/code/doc_src_examples_ahigl.qdoc 0
|
|---|
| 89 |
|
|---|
| 90 | The example driver also implements an animated transition effect
|
|---|
| 91 | for use when showing new windows or reshowing windows that have
|
|---|
| 92 | been minimized. To enable this transition effect, run the
|
|---|
| 93 | application with \c {-display ahigl:effects}.
|
|---|
| 94 |
|
|---|
| 95 | \section1 The Class Definitions
|
|---|
| 96 |
|
|---|
| 97 | The example comprises three main classes plus some helper classes.
|
|---|
| 98 | The three main classes are the plugin (QAhiGLScreenPlugin), which
|
|---|
| 99 | is defined in qscreenahiglplugin.cpp, the screen driver
|
|---|
| 100 | (QAhiGLScreen), which is defined in qscreenahigl_qws.h, and the
|
|---|
| 101 | window surface (QAhiGLWindowSurface), which is defined in
|
|---|
| 102 | qwindowsurface_ahigl_p.h. The "Ahi" prefix in these class names
|
|---|
| 103 | stands for \e {ATI Handheld Interface}. The example was written
|
|---|
| 104 | for the ATI Imageon 2380, but it can also be used as a template
|
|---|
| 105 | for other ATI handheld devices.
|
|---|
| 106 |
|
|---|
| 107 | \section2 The Plugin Class Definition
|
|---|
| 108 |
|
|---|
| 109 | The screen driver plugin is class QAhiGLScreenPlugin.
|
|---|
| 110 |
|
|---|
| 111 | \snippet examples/qws/ahigl/qscreenahiglplugin.cpp 0
|
|---|
| 112 |
|
|---|
| 113 | QAhiGLScreenPlugin is derived from class QScreenDriverPlugin,
|
|---|
| 114 | which in turn is derived from QObject.
|
|---|
| 115 |
|
|---|
| 116 | \section2 The Screen Driver Class Definitions
|
|---|
| 117 |
|
|---|
| 118 | The screen driver classes are the public class QAhiGLScreen and
|
|---|
| 119 | its private implementation class QAhiGLScreenPrivate. QAhiGLScreen
|
|---|
| 120 | is derived from QGLScreen, which is derived from QScreen. If your
|
|---|
| 121 | screen driver will only do window compositions and display them,
|
|---|
| 122 | then you can derive your screen driver class directly from
|
|---|
| 123 | QScreen. But if your screen driver will do accelerated graphics
|
|---|
| 124 | rendering operations with the QOpenGLPaintEngine, or if it will
|
|---|
| 125 | handle instances of class QGLWidget, then you must derive your
|
|---|
| 126 | screen driver class from QGLScreen.
|
|---|
| 127 |
|
|---|
| 128 | \snippet examples/qws/ahigl/qscreenahigl_qws.h 0
|
|---|
| 129 |
|
|---|
| 130 | All functions in the public API of class QAhiGLScreen are virtual
|
|---|
| 131 | functions declared in its base classes. hasOpenGL() is declared in
|
|---|
| 132 | QGLScreen. It simply returns true indicating our example screen
|
|---|
| 133 | driver does support OpenGL operations. The other functions in the
|
|---|
| 134 | public API are declared in QScreen. They are called by the
|
|---|
| 135 | \l{QWSServer}{Qt for Embedded Linux server} at the appropriate times.
|
|---|
| 136 |
|
|---|
| 137 | Note that class QScreen is a documented class but class QGLScreen
|
|---|
| 138 | is not. This is because the design of class QGLScreen is not yet
|
|---|
| 139 | final.
|
|---|
| 140 |
|
|---|
| 141 | The only data member in class QAhiGLScreen is a standard d_ptr,
|
|---|
| 142 | which points to an instance of the driver's private implementation
|
|---|
| 143 | class QAhiGLScreenPrivate. The driver's internal state is stored
|
|---|
| 144 | in the private class. Using the so-called d-pointer pattern allows
|
|---|
| 145 | you to make changes to the driver's internal design without
|
|---|
| 146 | breaking binary compatibility.
|
|---|
| 147 |
|
|---|
| 148 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 0
|
|---|
| 149 |
|
|---|
| 150 | Class QAhiGLScreenPrivate is derived from QObject so that it can
|
|---|
| 151 | use the Qt signal/slot mechanism. QAhiGLScreen is not a QObject,
|
|---|
| 152 | so it can't use the signal/slot mechanism. Signals meant for our
|
|---|
| 153 | screen driver are received by slots in the private implementation
|
|---|
| 154 | class, in this case, windowEvent() and redrawScreen().
|
|---|
| 155 |
|
|---|
| 156 | \section2 The Window Surface Class Definitions
|
|---|
| 157 |
|
|---|
| 158 | The window surface classes are QAhiGLWindowSurface and its private
|
|---|
| 159 | implementation class QAhiGLWindowSurfacePrivate. We create class
|
|---|
| 160 | QAhiGLWindowSurface so the screen driver can use the OpenGL paint
|
|---|
| 161 | engine and the OpenGL widget, classes QOpenGLPaintEngine and
|
|---|
| 162 | QGLWidget. QAhiGLWindowSurface is derived from the more general
|
|---|
| 163 | OpenGL window surface class, QWSGLWindowSurface, which is derived
|
|---|
| 164 | from QWSWindowSurface.
|
|---|
| 165 |
|
|---|
| 166 | \snippet examples/qws/ahigl/qwindowsurface_ahigl_p.h 0
|
|---|
| 167 |
|
|---|
| 168 | In addition to implementing the standard functionality required by
|
|---|
| 169 | any new subclass of QWSWindowSurface, QAhiGLWindowSurface also
|
|---|
| 170 | contains the textureId() function used by QAhiGLScreen.
|
|---|
| 171 |
|
|---|
| 172 | The same d-pointer pattern is used in this window surface class.
|
|---|
| 173 | The private implementation class is QAhiGLWindowSurfacePrivate. It
|
|---|
| 174 | allows making changes to the state variables of the window surface
|
|---|
| 175 | without breaking binary compatibility.
|
|---|
| 176 |
|
|---|
| 177 | \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 0
|
|---|
| 178 |
|
|---|
| 179 | In this case, our private implementation class has no member
|
|---|
| 180 | functions except for its constructor. It contains only public data
|
|---|
| 181 | members which hold state information for the window surface.
|
|---|
| 182 |
|
|---|
| 183 | \section2 The Helper Classes
|
|---|
| 184 |
|
|---|
| 185 | The example screen driver maintains a static \l {QMap} {map} of
|
|---|
| 186 | all the \l {QWSWindow} {windows} it is showing on the screen.
|
|---|
| 187 | Each window is mapped to an instance of struct WindowInfo.
|
|---|
| 188 |
|
|---|
| 189 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 2
|
|---|
| 190 |
|
|---|
| 191 | As each new window is created, an instance of struct WindowInfo is
|
|---|
| 192 | allocated and inserted into the window map. WindowInfo uses a
|
|---|
| 193 | GLuint to identify the OpenGL texture it creates for the window.
|
|---|
| 194 | Note that the example driver, in addition to drawing windows using
|
|---|
| 195 | OpenGL, also supports drawing windows in the normal way without
|
|---|
| 196 | OpenGL, but it uses an OpenGL texture for the rendering operations
|
|---|
| 197 | in either case. Top-level windows that are drawn without OpenGL
|
|---|
| 198 | are first rendered in the normal way into a shared memory segment,
|
|---|
| 199 | which is then converted to a OpenGL texture and drawn to the
|
|---|
| 200 | screen.
|
|---|
| 201 |
|
|---|
| 202 | To animate the window transition effect, WindowInfo uses an
|
|---|
| 203 | instance of the helper class ShowAnimation. The animation is
|
|---|
| 204 | created by the windowEvent() slot in QAhiGLScreenPrivate, whenever
|
|---|
| 205 | a \l {QWSServer::WindowEvent} {Show} window event is emitted by
|
|---|
| 206 | the \l {QWSServer} {window server}. The server emits this signal
|
|---|
| 207 | when a window is shown the first time and again later, when the
|
|---|
| 208 | window is reshown after having been minimized.
|
|---|
| 209 |
|
|---|
| 210 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 1
|
|---|
| 211 |
|
|---|
| 212 | Class ShowAnimation is derived from the QTimeLine class, which is
|
|---|
| 213 | used for controlling animations. QTimeLine is a QObject, so
|
|---|
| 214 | ShowAnimation can use the Qt signal/slot mechanism. We will see
|
|---|
| 215 | how the timeline's \l {QTimeLine::valueChanged()} {valueChanged()}
|
|---|
| 216 | and \l {QTimeLine::finished()} {finished()} signals are used to
|
|---|
| 217 | control the animation and then destroy the instance of
|
|---|
| 218 | ShowAnimation, when the animation ends. The ShowAnimation
|
|---|
| 219 | constructor needs the pointer to the screen driver's private
|
|---|
| 220 | implementation class so it can set up these signal/slot
|
|---|
| 221 | connections.
|
|---|
| 222 |
|
|---|
| 223 | \section1 The Class Implementations
|
|---|
| 224 |
|
|---|
| 225 | \section2 The Plugin Class Implementation
|
|---|
| 226 |
|
|---|
| 227 | QAhiGLScreenPlugin is a straightforward derivation of
|
|---|
| 228 | QScreenDriverPlugin. It reimplements \l{QScreenDriverPlugin::}{keys()}
|
|---|
| 229 | and \l{QScreenDriverPlugin::}{create()}. They are
|
|---|
| 230 | called as needed by the \l{QWSServer}{Qt for Embedded Linux server.}
|
|---|
| 231 | Recall that the server detects that the ahigl screen driver has
|
|---|
| 232 | been requested, either by including "ahigl" in the value for the
|
|---|
| 233 | environment variable QWS_DISPLAY, or by running your application
|
|---|
| 234 | with a command line like the following.
|
|---|
| 235 |
|
|---|
| 236 | \snippet doc/src/snippets/code/doc_src_examples_ahigl.qdoc 1
|
|---|
| 237 |
|
|---|
| 238 | The server calls \l {QScreenDriverPlugin::} {keys()}, which
|
|---|
| 239 | returns a \l {QStringList} containing the singleton "ahigl"
|
|---|
| 240 | matching the requested screen driver and telling the server that
|
|---|
| 241 | it can use our example screen driver. The server then calls \l
|
|---|
| 242 | {QScreenDriverPlugin::} {create()}, which creates the instance of
|
|---|
| 243 | QAhiGLScreen.
|
|---|
| 244 |
|
|---|
| 245 | \snippet examples/qws/ahigl/qscreenahiglplugin.cpp 1
|
|---|
| 246 |
|
|---|
| 247 | In the code snippet above, the macro Q_EXPORT_PLUGIN2 is used to export
|
|---|
| 248 | the plugin class, QAhiGLScreen, for the qahiglscreen plugin.
|
|---|
| 249 | Further information regarding plugins and how to create them
|
|---|
| 250 | can be found at \l{How to Create Qt Plugins}.
|
|---|
| 251 |
|
|---|
| 252 | \section2 The Screen Driver Class Implementations
|
|---|
| 253 |
|
|---|
| 254 | The plugin creates the singleton instance of QAhiGLScreen. The
|
|---|
| 255 | constructor is passed a \c displayId, which is used in the base
|
|---|
| 256 | class QGLScreen to identify the server that the screen driver is
|
|---|
| 257 | connected to. The constructor also creates its instance of
|
|---|
| 258 | QAhiGLScreenPrivate, which instantiates a QTimer. The timeout()
|
|---|
| 259 | signal of this timer is connected to the redrawScreen() slot so
|
|---|
| 260 | the timer can be used to limit the frequency of actual drawing
|
|---|
| 261 | operations in the hardware.
|
|---|
| 262 |
|
|---|
| 263 | The public API of class QAhiGLScreen consists of implementations
|
|---|
| 264 | of virtual functions declared in its base classes. The function
|
|---|
| 265 | hasOpenGL() is declared in base class QGLScreen. The others are
|
|---|
| 266 | declared in base class QScreen.
|
|---|
| 267 |
|
|---|
| 268 | The \l {QScreen::}{connect()} function is the first one called by
|
|---|
| 269 | the server after the screen driver is constructed. It initializes
|
|---|
| 270 | the QScreen data members to hardcoded values that describe the ATI
|
|---|
| 271 | screen. A better implementation would query the hardware for the
|
|---|
| 272 | corresponding values in its current state and use those. It asks
|
|---|
| 273 | whether the screen driver was started with the \c effects option
|
|---|
| 274 | and sets the \c doEffects flag accordingly.
|
|---|
| 275 |
|
|---|
| 276 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 7
|
|---|
| 277 |
|
|---|
| 278 | The \l {QScreen::}{initDevice()} function is called by the server
|
|---|
| 279 | after \l {QScreen::}{connect()}. It uses EGL library functions to
|
|---|
| 280 | initialize the ATI hardware. Note that some data structures used
|
|---|
| 281 | in this example are specific to the EGL implementation used, e.g.,
|
|---|
| 282 | the DummyScreen structure.
|
|---|
| 283 |
|
|---|
| 284 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 8
|
|---|
| 285 |
|
|---|
| 286 | Note the signal/slot connection at the bottom of initDevice(). We
|
|---|
| 287 | connect the server's QWSServer::windowEvent() signal to the
|
|---|
| 288 | windowEvent() slot in the screen driver's private implementation
|
|---|
| 289 | class. The windowEvent() slot handles three window events,
|
|---|
| 290 | QWSServer::Create, QWSServer::Destroy, and QWSServer::Show.
|
|---|
| 291 |
|
|---|
| 292 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 5
|
|---|
| 293 |
|
|---|
| 294 | The function manages instances of the helper classes associated
|
|---|
| 295 | with each window. When a QWSServer::Create event occurs, it means
|
|---|
| 296 | a new top-level \l {QWSWindow} {window} has been created. In this
|
|---|
| 297 | case, an instance of helper class WindowInfo is created and
|
|---|
| 298 | inserted into the window map with the pointer to the new \l
|
|---|
| 299 | {QWSWindow} {window} as its key. When a QWSServer::Destroy event
|
|---|
| 300 | occurs, a window is being destroyed, and its mapping is removed
|
|---|
| 301 | from the window map. These two events are straightforward. The
|
|---|
| 302 | tricky bits happen when a QWSServer::Show event occurs. This case
|
|---|
| 303 | occurs when a window is shown for the first time and when it is
|
|---|
| 304 | reshown after having been minimized. If the window transition
|
|---|
| 305 | effect has been enabled, a new instance of the helper class
|
|---|
| 306 | ShowAnimation is created and stored in a QPointer in the window's
|
|---|
| 307 | instance of WindowInfo. The constructor of ShowAnimation
|
|---|
| 308 | automatically \l {QTimeLine::start()} {starts} the animation of
|
|---|
| 309 | the transition effect.
|
|---|
| 310 |
|
|---|
| 311 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 3
|
|---|
| 312 |
|
|---|
| 313 | To ensure that a ShowAnimation is not deleted until its animation
|
|---|
| 314 | ends, the \l {QTimeLine::finished()} {finished()} signal is
|
|---|
| 315 | connected to the \l {QObject::deleteLater()} {deleteLater()} slot.
|
|---|
| 316 | When the animation ends, the finished() signal is emitted and the
|
|---|
| 317 | deleteLater() slot deletes the ShowAnimation. The key here is that
|
|---|
| 318 | the pointer to the ShowAnimation is stored in a QPointer in the
|
|---|
| 319 | WindowInfo class. This QPointer will also be notified when the
|
|---|
| 320 | ShowAnimation is deleted, so the QPointer in WindowInfo can null
|
|---|
| 321 | itself out, if and only if it is still pointing to the instance
|
|---|
| 322 | of ShowAnimation being deleted.
|
|---|
| 323 |
|
|---|
| 324 | The \l {QTimeLine::valueForTime()} {valueForTime()} function in
|
|---|
| 325 | QTimeLine is reimplemented in ShowAnimation to return time values
|
|---|
| 326 | that represent a curved path for the window transition effect.
|
|---|
| 327 |
|
|---|
| 328 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 4
|
|---|
| 329 |
|
|---|
| 330 | valueForTime() is called internally, when the time interval it
|
|---|
| 331 | computed during the previous call has elapsed. If it computes a
|
|---|
| 332 | next time value that is different from the one computed
|
|---|
| 333 | previously, the \l {QTimeLine::valueChanged()} {valueChanged()}
|
|---|
| 334 | signal is emitted. The ShowAnimation constructor shown above
|
|---|
| 335 | connects this signal to the redrawScreen() slot in the screen
|
|---|
| 336 | driver's private implementation class. This is how the animation
|
|---|
| 337 | actually happens.
|
|---|
| 338 |
|
|---|
| 339 | The screen driver's implementation of \l {QScreen::}
|
|---|
| 340 | {exposeRegion()} is where the main work of the screen driver is
|
|---|
| 341 | meant to be done, i.e., updating the screen. It is called by the
|
|---|
| 342 | \l {QWSServer} {window system} to update a particular window's
|
|---|
| 343 | region of the screen. But note that it doesn't actually update the
|
|---|
| 344 | screen, i.e., it doesn't actually call redrawScreen() directly,
|
|---|
| 345 | but starts the updateTimer, which causes redrawScreen() to be
|
|---|
| 346 | called once for each updateTimer interval. This means that all
|
|---|
| 347 | calls to exposeRegion() during an updateTimer interval are handled
|
|---|
| 348 | by a single call to redrawScreen(). Thus updateTimer can be used
|
|---|
| 349 | to limit the frequency of screen updates.
|
|---|
| 350 |
|
|---|
| 351 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 13
|
|---|
| 352 |
|
|---|
| 353 | The call to the private function invalidateTexture() destroys
|
|---|
| 354 | the window's existing texture (image). This ensures that a new
|
|---|
| 355 | texture will be created for the window, when redrawScreen() is
|
|---|
| 356 | eventually called.
|
|---|
| 357 |
|
|---|
| 358 | But there is a caveat to using updateTimer to limit the frequency
|
|---|
| 359 | of screen updates. When the driver's animated transition effect
|
|---|
| 360 | for new windows is enabled and a new window is being shown for the
|
|---|
| 361 | first time or reshown after having been minimized, an instance of
|
|---|
| 362 | ShowAnimation is created to run the animation. The valueChanged()
|
|---|
| 363 | signal of this ShowAnimation is also connected to the
|
|---|
| 364 | redrawScreen() slot, and QTimeLine, the base class of our
|
|---|
| 365 | ShowAnimation, uses its own, internal timer to limit the speed of
|
|---|
| 366 | the animation. This means that in the driver as currently written,
|
|---|
| 367 | if the window transition effect is enabled (i.e. if the plugin is
|
|---|
| 368 | started, with \c {-display ahigl:effects}), then redrawScreen()
|
|---|
| 369 | can be called both when the update timer times out and when the
|
|---|
| 370 | ShowAnimation timer times out, so the screen might get updated
|
|---|
| 371 | more often than the frequency established by the update timer.
|
|---|
| 372 | This may or may not be a bug, depending on your own hardware, if
|
|---|
| 373 | you use this example as a template for your own OpenGL driver.
|
|---|
| 374 |
|
|---|
| 375 | The screen driver's private function redrawScreen() constructs
|
|---|
| 376 | the window compositions. It is called only by the function of the
|
|---|
| 377 | same name in the screen driver's private implementation class.
|
|---|
| 378 |
|
|---|
| 379 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 6
|
|---|
| 380 |
|
|---|
| 381 | Recall that this redrawScreen() in the private implementation
|
|---|
| 382 | class is a slot function connected to two signals, the \c
|
|---|
| 383 | timeout() signal of the updateTimer in the private implementation
|
|---|
| 384 | class, and the valueChanged() signal of the helper class
|
|---|
| 385 | ShowAnimation. Thus, the screen is only ever updated when a
|
|---|
| 386 | timeout of one of the two timers occurs. This is important for two
|
|---|
| 387 | reasons. First, the screen is meant to be updated no more than
|
|---|
| 388 | once per updateTimer interval. Second, however, if the animated
|
|---|
| 389 | window transition effect is requested, the screen might be updated
|
|---|
| 390 | more often than that, and this might be a bug if the hardware
|
|---|
| 391 | can't handle more frequent updates.
|
|---|
| 392 |
|
|---|
| 393 | The redrawScreen() in QAhiGLScreen begins by using standard
|
|---|
| 394 | OpenGL to fill the screen with the background color.
|
|---|
| 395 |
|
|---|
| 396 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 10
|
|---|
| 397 |
|
|---|
| 398 | Next it iterates over the list of all \l {QWSWindow} {client
|
|---|
| 399 | windows} obtained from the \l {QWSServer} {server}, extracting
|
|---|
| 400 | from each window its instance of QWSWIndowSurface, then using that
|
|---|
| 401 | window surface to create an OpenGL texture, and finally calling
|
|---|
| 402 | the helper function drawWindow() to draw the texture on the
|
|---|
| 403 | screen.
|
|---|
| 404 |
|
|---|
| 405 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 11
|
|---|
| 406 |
|
|---|
| 407 | Note the call to glBindTexture() immediately before the call to
|
|---|
| 408 | drawWindow(). This call binds the identifer \c GL_TEXTURE_2D to
|
|---|
| 409 | the texture we have just created. This makes our texture
|
|---|
| 410 | accessible to functions in the OpenGL libraries. If you miss that
|
|---|
| 411 | point, digging into the internals of drawWindow() won't make much
|
|---|
| 412 | sense.
|
|---|
| 413 |
|
|---|
| 414 | Finally, the cursor is added to the window composition, and in the
|
|---|
| 415 | last statement, the whole thing is displayed on the screen.
|
|---|
| 416 |
|
|---|
| 417 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 12
|
|---|
| 418 |
|
|---|
| 419 | The call to \c drawWindow(win,progress), in addition to passing a
|
|---|
| 420 | pointer to the window to be redrawn, also passes the \c progress
|
|---|
| 421 | parameter obtained by calling \l {QTimeLine::currentValue()} on
|
|---|
| 422 | the window's instance of ShowAnimation. Recall that the current
|
|---|
| 423 | value of the timeline is updated internally by a timer local to
|
|---|
| 424 | the timeline, and the redrawScreen() slot is called whenever the
|
|---|
| 425 | current value changes. The progress value will only be used if
|
|---|
| 426 | the animated transition effect has been enabled. These extra calls
|
|---|
| 427 | of redrawScreen() may cause the screen to be updated more often
|
|---|
| 428 | than the rate determined by updateTimer. This must be taken
|
|---|
| 429 | into account, if you set your updateTimer to timeout at the
|
|---|
| 430 | maximum screen update frequency your hardware can handle.
|
|---|
| 431 |
|
|---|
| 432 | The drawWindow() function is not shown here and not explained
|
|---|
| 433 | further, but the call to drawWindow() is the entry point to a
|
|---|
| 434 | hierarchy of private helper functions that execute sequences of
|
|---|
| 435 | OpenGL and EGL library calls. The reader is assumed to be familiar
|
|---|
| 436 | enough with the OpenGL and EGL APIs to understand the code in
|
|---|
| 437 | these helper functions on his own. Besides drawWindow(), the list
|
|---|
| 438 | of these helper functions includes drawQuad(), drawQuadWavyFlag(),
|
|---|
| 439 | the two overloadings of drawQuad_helper() (used by drawQuad() and
|
|---|
| 440 | drawQuadWacyFlag()), and setRectCoords().
|
|---|
| 441 |
|
|---|
| 442 | Note the two different ways the window's texture can be created in
|
|---|
| 443 | redrawScreen(). If the window surface is an OpenGL window surface
|
|---|
| 444 | (QAhiGLWindowSurface described below), the texture is obtained
|
|---|
| 445 | from the window surface directly by calling its textureId()
|
|---|
| 446 | function. But when the window surface is not an OpenGL one, the
|
|---|
| 447 | static function createTexture() is called with the window
|
|---|
| 448 | surface's \l {QImage} {image} to copy that image into an OpenGL
|
|---|
| 449 | texture. This is done with the EGL functions glTexImage2D() and
|
|---|
| 450 | glTexSubImage2D(). createTexture() is another function that
|
|---|
| 451 | should be understandable for exsperienced OpenGL users, so it is
|
|---|
| 452 | not shown or explained further here.
|
|---|
| 453 |
|
|---|
| 454 | The two implementations of \l {QScreen::}{createSurface()} are for
|
|---|
| 455 | instantiating new window surfaces. The overloading with the widget
|
|---|
| 456 | parameter is called in the client.
|
|---|
| 457 |
|
|---|
| 458 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 14
|
|---|
| 459 |
|
|---|
| 460 | If the parameter is an \l {QGLWidget} {OpenGL widget}, or, when it
|
|---|
| 461 | isn't an OpenGL widget but its size is no bigger than 256 x 256,
|
|---|
| 462 | we instantiate our subclass QAhiGLWindowSurface. Otherwise, we
|
|---|
| 463 | instantiate a QWSWindowSurface. The size contraint is a
|
|---|
| 464 | limitation of the OpenGL ES libraries we are using for our ATI
|
|---|
| 465 | device.
|
|---|
| 466 |
|
|---|
| 467 | Note the test at the top of the function asking if our application
|
|---|
| 468 | process is the \l {QApplication::GuiServer} {server}. We only
|
|---|
| 469 | create instances of QAhiGLWindowSurface if our client is in the
|
|---|
| 470 | server process. This is because of an implementation restriction
|
|---|
| 471 | required by the OpenGL library used in the example. They only
|
|---|
| 472 | support use of OpenGL in the server process. Hence a client can
|
|---|
| 473 | use the QAhiGLWindowSurface if the client is in the server
|
|---|
| 474 | process.
|
|---|
| 475 |
|
|---|
| 476 | The other overloading of createSurface() is called by the
|
|---|
| 477 | server to create a window surface that will hold a copy of a
|
|---|
| 478 | client side window surface.
|
|---|
| 479 |
|
|---|
| 480 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 15
|
|---|
| 481 |
|
|---|
| 482 | This overloading accepts a QString parameter identifying the type
|
|---|
| 483 | of window surface to instantiate. QAhiGLWindowSurface is
|
|---|
| 484 | instantiated if the parameter is \c ahigl. Otherwise, a normal
|
|---|
| 485 | QWSWindowSurface is instantiated. The client's window surface
|
|---|
| 486 | communicates its image data to the server's window surface through
|
|---|
| 487 | shared memory.
|
|---|
| 488 |
|
|---|
| 489 | The implementation of \l {QScreen::}{setMode()}, is a stub in this
|
|---|
| 490 | example. It would normally reset the frame buffer's resolution.
|
|---|
| 491 | Its parameters are the \e width, \e height, and the bit \e depth
|
|---|
| 492 | for the frame buffer's new resolution. If you implement setMode()
|
|---|
| 493 | in your screen driver, remember that it must emit a signal to warn
|
|---|
| 494 | other applications to redraw their frame buffers with the new
|
|---|
| 495 | resolution. There is no significance to setMode() not being
|
|---|
| 496 | implemented in this example. It simply wasn't implemented.
|
|---|
| 497 | However, the stub had to be included because QScreen declares
|
|---|
| 498 | setMode() to be pure virtual.
|
|---|
| 499 |
|
|---|
| 500 | Before the application exits, the server will call \l {QScreen::}
|
|---|
| 501 | {shutdownDevice()} to release the hardware resources. This is also
|
|---|
| 502 | done using EGL library functions.
|
|---|
| 503 |
|
|---|
| 504 | \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 9
|
|---|
| 505 |
|
|---|
| 506 | The server will also call \l {QScreen::}{disconnect()}, but this
|
|---|
| 507 | function is only a stub in this example.
|
|---|
| 508 |
|
|---|
| 509 | \section2 The window Surface Class Implementations
|
|---|
| 510 |
|
|---|
| 511 | QAhiGLScreen creates instances of QAhiGLWindowSurface in its two
|
|---|
| 512 | createSurface() functions, and there are two constructors for
|
|---|
| 513 | QAhiGLWindowSurface that correspond to these two versions of
|
|---|
| 514 | createSurface(). The constructor accepting a \l {QWidget} {widget}
|
|---|
| 515 | parameter is called by the client side version of createSurface(),
|
|---|
| 516 | and the constructor without the \l {QWidget} {widget} parameter is
|
|---|
| 517 | called by the server side version. There will be a window surface
|
|---|
| 518 | constructed on the server side for each one constructed on the
|
|---|
| 519 | client side.
|
|---|
| 520 |
|
|---|
| 521 | \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 1
|
|---|
| 522 | \codeline
|
|---|
| 523 | \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 2
|
|---|
| 524 |
|
|---|
| 525 | The constructors create an instance of QAhiGLWindowSurfacePrivate,
|
|---|
| 526 | the private implementation class, which contains all the state
|
|---|
| 527 | variables for QAhiGLWindowSurface. The client side constructor
|
|---|
| 528 | also creates an instance of QWSGLPaintDevice, the OpenGL paint
|
|---|
| 529 | device, for return by \l {QWSWindowSurface::} {paintDevice()}.
|
|---|
| 530 | This ensures that all \l {QPainter}s used on this surface will use
|
|---|
| 531 | an OpenGL enabled QPaintEngine. It is a bit of jiggery pokery,
|
|---|
| 532 | which is required because \l {QWSWindowSurface::} {paintDevice()}
|
|---|
| 533 | is declared pure virtual. Normally, the client side constructor
|
|---|
| 534 | will be called with an \l {QGLWidget}{OpenGL widget}, which has
|
|---|
| 535 | its own \l {QWidget::} {paintEngine()} function that returns the
|
|---|
| 536 | global static OpenGL paint engine, but because the constructor
|
|---|
| 537 | also accepts a normal \l {QWidget}{widget}, it must be able to
|
|---|
| 538 | find the OpenGL paint engine in that case as well, so since \l
|
|---|
| 539 | {QWSWindowSurface::} {paintDevice()} must be implemented anyway,
|
|---|
| 540 | the constructor creates an instance of QWSGLPaintDevice, which can
|
|---|
| 541 | always return the global static pointer to QOpenGLPaintEngine.
|
|---|
| 542 |
|
|---|
| 543 | The OpenGL library implementation used for this example only
|
|---|
| 544 | supports one OpenGL context. This context is therefore shared
|
|---|
| 545 | among the single instance of QAhiGLScreen and all instances of
|
|---|
| 546 | QAhiGLWindowSurface. It is passed to both constructors.
|
|---|
| 547 |
|
|---|
| 548 | This example uses the OpenGL frame buffer object extension, which
|
|---|
| 549 | allows for accelerating OpenGL painting operations. Using this
|
|---|
| 550 | OpenGL extension, painting operations are performed in a frame
|
|---|
| 551 | buffer object, which QAhiGLScreen later uses to construct window
|
|---|
| 552 | compositions on the screen. Allocation of the frame buffer object
|
|---|
| 553 | is performed in \l {QWindowSurface::} {setGeometry()}. A safer way
|
|---|
| 554 | to use this extension would be to first test to see if the
|
|---|
| 555 | extension is supported by your OpenGL library, and use a different
|
|---|
| 556 | approach if it is not.
|
|---|
| 557 |
|
|---|
| 558 | \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 3
|
|---|
| 559 |
|
|---|
| 560 | Since there can be several instances of the QAhiGLWindowSurface, we need
|
|---|
| 561 | to make sure that the correct framebuffer object is active before painting.
|
|---|
| 562 | This is done by reimplementing \l QWindowSurface::beginPaint():
|
|---|
| 563 |
|
|---|
| 564 | \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 4
|
|---|
| 565 |
|
|---|
| 566 | Finally we need to make sure that whenever a widget grows beyond the size
|
|---|
| 567 | supported by this driver (256 x 256), the surface is deleted and a new
|
|---|
| 568 | standard surface is created instead. This is handled by reimplementing
|
|---|
| 569 | \l QWSWindowSurface::isValid():
|
|---|
| 570 |
|
|---|
| 571 | \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 5
|
|---|
| 572 | */
|
|---|