summaryrefslogtreecommitdiffstats
path: root/doc/src/examples/ahigl.qdoc
diff options
context:
space:
mode:
Diffstat (limited to 'doc/src/examples/ahigl.qdoc')
-rw-r--r--doc/src/examples/ahigl.qdoc572
1 files changed, 0 insertions, 572 deletions
diff --git a/doc/src/examples/ahigl.qdoc b/doc/src/examples/ahigl.qdoc
deleted file mode 100644
index c5e2387..0000000
--- a/doc/src/examples/ahigl.qdoc
+++ /dev/null
@@ -1,572 +0,0 @@
-/****************************************************************************
-**
-** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
-** All rights reserved.
-** 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 Technology Preview License Agreement accompanying
-** this package.
-**
-** 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.1, included in the file LGPL_EXCEPTION.txt in this package.
-**
-** If you have questions regarding the use of this file, please contact
-** Nokia at qt-info@nokia.com.
-**
-**
-**
-**
-**
-**
-**
-**
-** $QT_END_LICENSE$
-**
-****************************************************************************/
-
-/*!
- \example qws/ahigl
- \title OpenGL for Embedded Systems Example
-
- \section1 Introduction
-
- This example demonstrates how you can use OpenGL for Embedded
- Systems (ES) in your own screen driver and \l{add your graphics
- driver to Qt for Embedded Linux}. In \l{Qt for Embedded Linux},
- painting is done in software, normally performed in two steps:
- First, each client renders its windows onto its window surface in
- memory using a paint engine. Then the server uses the screen
- driver to compose the window surface images and copy the
- composition to the screen. (See the \l{Qt for Embedded Linux
- Architecture} documentation for details.)
-
- This example is not for the novice. It assumes the reader is
- familiar with both OpenGL and the screen driver framework
- demonstrated in the \l {Accelerated Graphics Driver Example}.
-
- An OpenGL screen driver for Qt for Embedded Linux can use OpenGL ES
- in three ways. First, the \l{QWSServer}{Qt for Embedded Linux server}
- can use the driver to compose multiple window images and then show the
- composition on the screen. Second, clients can use the driver to
- accelerate OpenGL painting operations using the QOpenGLPaintEngine
- class. Finally, clients can use the driver to do OpenGL operations
- with instances of the QGLWidget class. This example implements all
- three cases.
-
- The example uses an implementation of OpenGL ES from
- \l {http://ati.amd.com}{ATI} for the
- \l {http://ati.amd.com/products/imageon238x/}{Imageon 2380}. The
- OpenGL include files gl.h and egl.h must be installed to compile
- the example, and the OpenGL and EGL libraries must be installed
- for linking. If your target device is different, you must install
- the include files and libraries for that device, and you also
- might need to modify the example source code, if any API signatures
- in your EGL library differ from the ones used here.
-
- After compiling and linking the example source, install the
- screen driver plugin with the command \c {make install}. To
- start an application that uses the plugin, you can either set the
- environment variable \l QWS_DISPLAY and then start the
- application, or just start the application with the \c -display
- switch, as follows:
-
- \snippet doc/src/snippets/code/doc_src_examples_ahigl.qdoc 0
-
- The example driver also implements an animated transition effect
- for use when showing new windows or reshowing windows that have
- been minimized. To enable this transition effect, run the
- application with \c {-display ahigl:effects}.
-
- \section1 The Class Definitions
-
- The example comprises three main classes plus some helper classes.
- The three main classes are the plugin (QAhiGLScreenPlugin), which
- is defined in qscreenahiglplugin.cpp, the screen driver
- (QAhiGLScreen), which is defined in qscreenahigl_qws.h, and the
- window surface (QAhiGLWindowSurface), which is defined in
- qwindowsurface_ahigl_p.h. The "Ahi" prefix in these class names
- stands for \e {ATI Handheld Interface}. The example was written
- for the ATI Imageon 2380, but it can also be used as a template
- for other ATI handheld devices.
-
- \section2 The Plugin Class Definition
-
- The screen driver plugin is class QAhiGLScreenPlugin.
-
- \snippet examples/qws/ahigl/qscreenahiglplugin.cpp 0
-
- QAhiGLScreenPlugin is derived from class QScreenDriverPlugin,
- which in turn is derived from QObject.
-
- \section2 The Screen Driver Class Definitions
-
- The screen driver classes are the public class QAhiGLScreen and
- its private implementation class QAhiGLScreenPrivate. QAhiGLScreen
- is derived from QGLScreen, which is derived from QScreen. If your
- screen driver will only do window compositions and display them,
- then you can derive your screen driver class directly from
- QScreen. But if your screen driver will do accelerated graphics
- rendering operations with the QOpenGLPaintEngine, or if it will
- handle instances of class QGLWidget, then you must derive your
- screen driver class from QGLScreen.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.h 0
-
- All functions in the public API of class QAhiGLScreen are virtual
- functions declared in its base classes. hasOpenGL() is declared in
- QGLScreen. It simply returns true indicating our example screen
- driver does support OpenGL operations. The other functions in the
- public API are declared in QScreen. They are called by the
- \l{QWSServer}{Qt for Embedded Linux server} at the appropriate times.
-
- Note that class QScreen is a documented class but class QGLScreen
- is not. This is because the design of class QGLScreen is not yet
- final.
-
- The only data member in class QAhiGLScreen is a standard d_ptr,
- which points to an instance of the driver's private implementation
- class QAhiGLScreenPrivate. The driver's internal state is stored
- in the private class. Using the so-called d-pointer pattern allows
- you to make changes to the driver's internal design without
- breaking binary compatibility.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 0
-
- Class QAhiGLScreenPrivate is derived from QObject so that it can
- use the Qt signal/slot mechanism. QAhiGLScreen is not a QObject,
- so it can't use the signal/slot mechanism. Signals meant for our
- screen driver are received by slots in the private implementation
- class, in this case, windowEvent() and redrawScreen().
-
- \section2 The Window Surface Class Definitions
-
- The window surface classes are QAhiGLWindowSurface and its private
- implementation class QAhiGLWindowSurfacePrivate. We create class
- QAhiGLWindowSurface so the screen driver can use the OpenGL paint
- engine and the OpenGL widget, classes QOpenGLPaintEngine and
- QGLWidget. QAhiGLWindowSurface is derived from the more general
- OpenGL window surface class, QWSGLWindowSurface, which is derived
- from QWSWindowSurface.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl_p.h 0
-
- In addition to implementing the standard functionality required by
- any new subclass of QWSWindowSurface, QAhiGLWindowSurface also
- contains the textureId() function used by QAhiGLScreen.
-
- The same d-pointer pattern is used in this window surface class.
- The private implementation class is QAhiGLWindowSurfacePrivate. It
- allows making changes to the state variables of the window surface
- without breaking binary compatibility.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 0
-
- In this case, our private implementation class has no member
- functions except for its constructor. It contains only public data
- members which hold state information for the window surface.
-
- \section2 The Helper Classes
-
- The example screen driver maintains a static \l {QMap} {map} of
- all the \l {QWSWindow} {windows} it is showing on the screen.
- Each window is mapped to an instance of struct WindowInfo.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 2
-
- As each new window is created, an instance of struct WindowInfo is
- allocated and inserted into the window map. WindowInfo uses a
- GLuint to identify the OpenGL texture it creates for the window.
- Note that the example driver, in addition to drawing windows using
- OpenGL, also supports drawing windows in the normal way without
- OpenGL, but it uses an OpenGL texture for the rendering operations
- in either case. Top-level windows that are drawn without OpenGL
- are first rendered in the normal way into a shared memory segment,
- which is then converted to a OpenGL texture and drawn to the
- screen.
-
- To animate the window transition effect, WindowInfo uses an
- instance of the helper class ShowAnimation. The animation is
- created by the windowEvent() slot in QAhiGLScreenPrivate, whenever
- a \l {QWSServer::WindowEvent} {Show} window event is emitted by
- the \l {QWSServer} {window server}. The server emits this signal
- when a window is shown the first time and again later, when the
- window is reshown after having been minimized.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 1
-
- Class ShowAnimation is derived from the QTimeLine class, which is
- used for controlling animations. QTimeLine is a QObject, so
- ShowAnimation can use the Qt signal/slot mechanism. We will see
- how the timeline's \l {QTimeLine::valueChanged()} {valueChanged()}
- and \l {QTimeLine::finished()} {finished()} signals are used to
- control the animation and then destroy the instance of
- ShowAnimation, when the animation ends. The ShowAnimation
- constructor needs the pointer to the screen driver's private
- implementation class so it can set up these signal/slot
- connections.
-
- \section1 The Class Implementations
-
- \section2 The Plugin Class Implementation
-
- QAhiGLScreenPlugin is a straightforward derivation of
- QScreenDriverPlugin. It reimplements \l{QScreenDriverPlugin::}{keys()}
- and \l{QScreenDriverPlugin::}{create()}. They are
- called as needed by the \l{QWSServer}{Qt for Embedded Linux server.}
- Recall that the server detects that the ahigl screen driver has
- been requested, either by including "ahigl" in the value for the
- environment variable QWS_DISPLAY, or by running your application
- with a command line like the following.
-
- \snippet doc/src/snippets/code/doc_src_examples_ahigl.qdoc 1
-
- The server calls \l {QScreenDriverPlugin::} {keys()}, which
- returns a \l {QStringList} containing the singleton "ahigl"
- matching the requested screen driver and telling the server that
- it can use our example screen driver. The server then calls \l
- {QScreenDriverPlugin::} {create()}, which creates the instance of
- QAhiGLScreen.
-
- \snippet examples/qws/ahigl/qscreenahiglplugin.cpp 1
-
- In the code snippet above, the macro Q_EXPORT_PLUGIN2 is used to export
- the plugin class, QAhiGLScreen, for the qahiglscreen plugin.
- Further information regarding plugins and how to create them
- can be found at \l{How to Create Qt Plugins}.
-
- \section2 The Screen Driver Class Implementations
-
- The plugin creates the singleton instance of QAhiGLScreen. The
- constructor is passed a \c displayId, which is used in the base
- class QGLScreen to identify the server that the screen driver is
- connected to. The constructor also creates its instance of
- QAhiGLScreenPrivate, which instantiates a QTimer. The timeout()
- signal of this timer is connected to the redrawScreen() slot so
- the timer can be used to limit the frequency of actual drawing
- operations in the hardware.
-
- The public API of class QAhiGLScreen consists of implementations
- of virtual functions declared in its base classes. The function
- hasOpenGL() is declared in base class QGLScreen. The others are
- declared in base class QScreen.
-
- The \l {QScreen::}{connect()} function is the first one called by
- the server after the screen driver is constructed. It initializes
- the QScreen data members to hardcoded values that describe the ATI
- screen. A better implementation would query the hardware for the
- corresponding values in its current state and use those. It asks
- whether the screen driver was started with the \c effects option
- and sets the \c doEffects flag accordingly.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 7
-
- The \l {QScreen::}{initDevice()} function is called by the server
- after \l {QScreen::}{connect()}. It uses EGL library functions to
- initialize the ATI hardware. Note that some data structures used
- in this example are specific to the EGL implementation used, e.g.,
- the DummyScreen structure.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 8
-
- Note the signal/slot connection at the bottom of initDevice(). We
- connect the server's QWSServer::windowEvent() signal to the
- windowEvent() slot in the screen driver's private implementation
- class. The windowEvent() slot handles three window events,
- QWSServer::Create, QWSServer::Destroy, and QWSServer::Show.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 5
-
- The function manages instances of the helper classes associated
- with each window. When a QWSServer::Create event occurs, it means
- a new top-level \l {QWSWindow} {window} has been created. In this
- case, an instance of helper class WindowInfo is created and
- inserted into the window map with the pointer to the new \l
- {QWSWindow} {window} as its key. When a QWSServer::Destroy event
- occurs, a window is being destroyed, and its mapping is removed
- from the window map. These two events are straightforward. The
- tricky bits happen when a QWSServer::Show event occurs. This case
- occurs when a window is shown for the first time and when it is
- reshown after having been minimized. If the window transition
- effect has been enabled, a new instance of the helper class
- ShowAnimation is created and stored in a QPointer in the window's
- instance of WindowInfo. The constructor of ShowAnimation
- automatically \l {QTimeLine::start()} {starts} the animation of
- the transition effect.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 3
-
- To ensure that a ShowAnimation is not deleted until its animation
- ends, the \l {QTimeLine::finished()} {finished()} signal is
- connected to the \l {QObject::deleteLater()} {deleteLater()} slot.
- When the animation ends, the finished() signal is emitted and the
- deleteLater() slot deletes the ShowAnimation. The key here is that
- the pointer to the ShowAnimation is stored in a QPointer in the
- WindowInfo class. This QPointer will also be notified when the
- ShowAnimation is deleted, so the QPointer in WindowInfo can null
- itself out, if and only if it is still pointing to the instance
- of ShowAnimation being deleted.
-
- The \l {QTimeLine::valueForTime()} {valueForTime()} function in
- QTimeLine is reimplemented in ShowAnimation to return time values
- that represent a curved path for the window transition effect.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 4
-
- valueForTime() is called internally, when the time interval it
- computed during the previous call has elapsed. If it computes a
- next time value that is different from the one computed
- previously, the \l {QTimeLine::valueChanged()} {valueChanged()}
- signal is emitted. The ShowAnimation constructor shown above
- connects this signal to the redrawScreen() slot in the screen
- driver's private implementation class. This is how the animation
- actually happens.
-
- The screen driver's implementation of \l {QScreen::}
- {exposeRegion()} is where the main work of the screen driver is
- meant to be done, i.e., updating the screen. It is called by the
- \l {QWSServer} {window system} to update a particular window's
- region of the screen. But note that it doesn't actually update the
- screen, i.e., it doesn't actually call redrawScreen() directly,
- but starts the updateTimer, which causes redrawScreen() to be
- called once for each updateTimer interval. This means that all
- calls to exposeRegion() during an updateTimer interval are handled
- by a single call to redrawScreen(). Thus updateTimer can be used
- to limit the frequency of screen updates.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 13
-
- The call to the private function invalidateTexture() destroys
- the window's existing texture (image). This ensures that a new
- texture will be created for the window, when redrawScreen() is
- eventually called.
-
- But there is a caveat to using updateTimer to limit the frequency
- of screen updates. When the driver's animated transition effect
- for new windows is enabled and a new window is being shown for the
- first time or reshown after having been minimized, an instance of
- ShowAnimation is created to run the animation. The valueChanged()
- signal of this ShowAnimation is also connected to the
- redrawScreen() slot, and QTimeLine, the base class of our
- ShowAnimation, uses its own, internal timer to limit the speed of
- the animation. This means that in the driver as currently written,
- if the window transition effect is enabled (i.e. if the plugin is
- started, with \c {-display ahigl:effects}), then redrawScreen()
- can be called both when the update timer times out and when the
- ShowAnimation timer times out, so the screen might get updated
- more often than the frequency established by the update timer.
- This may or may not be a bug, depending on your own hardware, if
- you use this example as a template for your own OpenGL driver.
-
- The screen driver's private function redrawScreen() constructs
- the window compositions. It is called only by the function of the
- same name in the screen driver's private implementation class.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 6
-
- Recall that this redrawScreen() in the private implementation
- class is a slot function connected to two signals, the \c
- timeout() signal of the updateTimer in the private implementation
- class, and the valueChanged() signal of the helper class
- ShowAnimation. Thus, the screen is only ever updated when a
- timeout of one of the two timers occurs. This is important for two
- reasons. First, the screen is meant to be updated no more than
- once per updateTimer interval. Second, however, if the animated
- window transition effect is requested, the screen might be updated
- more often than that, and this might be a bug if the hardware
- can't handle more frequent updates.
-
- The redrawScreen() in QAhiGLScreen begins by using standard
- OpenGL to fill the screen with the background color.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 10
-
- Next it iterates over the list of all \l {QWSWindow} {client
- windows} obtained from the \l {QWSServer} {server}, extracting
- from each window its instance of QWSWIndowSurface, then using that
- window surface to create an OpenGL texture, and finally calling
- the helper function drawWindow() to draw the texture on the
- screen.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 11
-
- Note the call to glBindTexture() immediately before the call to
- drawWindow(). This call binds the identifer \c GL_TEXTURE_2D to
- the texture we have just created. This makes our texture
- accessible to functions in the OpenGL libraries. If you miss that
- point, digging into the internals of drawWindow() won't make much
- sense.
-
- Finally, the cursor is added to the window composition, and in the
- last statement, the whole thing is displayed on the screen.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 12
-
- The call to \c drawWindow(win,progress), in addition to passing a
- pointer to the window to be redrawn, also passes the \c progress
- parameter obtained by calling \l {QTimeLine::currentValue()} on
- the window's instance of ShowAnimation. Recall that the current
- value of the timeline is updated internally by a timer local to
- the timeline, and the redrawScreen() slot is called whenever the
- current value changes. The progress value will only be used if
- the animated transition effect has been enabled. These extra calls
- of redrawScreen() may cause the screen to be updated more often
- than the rate determined by updateTimer. This must be taken
- into account, if you set your updateTimer to timeout at the
- maximum screen update frequency your hardware can handle.
-
- The drawWindow() function is not shown here and not explained
- further, but the call to drawWindow() is the entry point to a
- hierarchy of private helper functions that execute sequences of
- OpenGL and EGL library calls. The reader is assumed to be familiar
- enough with the OpenGL and EGL APIs to understand the code in
- these helper functions on his own. Besides drawWindow(), the list
- of these helper functions includes drawQuad(), drawQuadWavyFlag(),
- the two overloadings of drawQuad_helper() (used by drawQuad() and
- drawQuadWacyFlag()), and setRectCoords().
-
- Note the two different ways the window's texture can be created in
- redrawScreen(). If the window surface is an OpenGL window surface
- (QAhiGLWindowSurface described below), the texture is obtained
- from the window surface directly by calling its textureId()
- function. But when the window surface is not an OpenGL one, the
- static function createTexture() is called with the window
- surface's \l {QImage} {image} to copy that image into an OpenGL
- texture. This is done with the EGL functions glTexImage2D() and
- glTexSubImage2D(). createTexture() is another function that
- should be understandable for exsperienced OpenGL users, so it is
- not shown or explained further here.
-
- The two implementations of \l {QScreen::}{createSurface()} are for
- instantiating new window surfaces. The overloading with the widget
- parameter is called in the client.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 14
-
- If the parameter is an \l {QGLWidget} {OpenGL widget}, or, when it
- isn't an OpenGL widget but its size is no bigger than 256 x 256,
- we instantiate our subclass QAhiGLWindowSurface. Otherwise, we
- instantiate a QWSWindowSurface. The size contraint is a
- limitation of the OpenGL ES libraries we are using for our ATI
- device.
-
- Note the test at the top of the function asking if our application
- process is the \l {QApplication::GuiServer} {server}. We only
- create instances of QAhiGLWindowSurface if our client is in the
- server process. This is because of an implementation restriction
- required by the OpenGL library used in the example. They only
- support use of OpenGL in the server process. Hence a client can
- use the QAhiGLWindowSurface if the client is in the server
- process.
-
- The other overloading of createSurface() is called by the
- server to create a window surface that will hold a copy of a
- client side window surface.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 15
-
- This overloading accepts a QString parameter identifying the type
- of window surface to instantiate. QAhiGLWindowSurface is
- instantiated if the parameter is \c ahigl. Otherwise, a normal
- QWSWindowSurface is instantiated. The client's window surface
- communicates its image data to the server's window surface through
- shared memory.
-
- The implementation of \l {QScreen::}{setMode()}, is a stub in this
- example. It would normally reset the frame buffer's resolution.
- Its parameters are the \e width, \e height, and the bit \e depth
- for the frame buffer's new resolution. If you implement setMode()
- in your screen driver, remember that it must emit a signal to warn
- other applications to redraw their frame buffers with the new
- resolution. There is no significance to setMode() not being
- implemented in this example. It simply wasn't implemented.
- However, the stub had to be included because QScreen declares
- setMode() to be pure virtual.
-
- Before the application exits, the server will call \l {QScreen::}
- {shutdownDevice()} to release the hardware resources. This is also
- done using EGL library functions.
-
- \snippet examples/qws/ahigl/qscreenahigl_qws.cpp 9
-
- The server will also call \l {QScreen::}{disconnect()}, but this
- function is only a stub in this example.
-
- \section2 The window Surface Class Implementations
-
- QAhiGLScreen creates instances of QAhiGLWindowSurface in its two
- createSurface() functions, and there are two constructors for
- QAhiGLWindowSurface that correspond to these two versions of
- createSurface(). The constructor accepting a \l {QWidget} {widget}
- parameter is called by the client side version of createSurface(),
- and the constructor without the \l {QWidget} {widget} parameter is
- called by the server side version. There will be a window surface
- constructed on the server side for each one constructed on the
- client side.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 1
- \codeline
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 2
-
- The constructors create an instance of QAhiGLWindowSurfacePrivate,
- the private implementation class, which contains all the state
- variables for QAhiGLWindowSurface. The client side constructor
- also creates an instance of QWSGLPaintDevice, the OpenGL paint
- device, for return by \l {QWSWindowSurface::} {paintDevice()}.
- This ensures that all \l {QPainter}s used on this surface will use
- an OpenGL enabled QPaintEngine. It is a bit of jiggery pokery,
- which is required because \l {QWSWindowSurface::} {paintDevice()}
- is declared pure virtual. Normally, the client side constructor
- will be called with an \l {QGLWidget}{OpenGL widget}, which has
- its own \l {QWidget::} {paintEngine()} function that returns the
- global static OpenGL paint engine, but because the constructor
- also accepts a normal \l {QWidget}{widget}, it must be able to
- find the OpenGL paint engine in that case as well, so since \l
- {QWSWindowSurface::} {paintDevice()} must be implemented anyway,
- the constructor creates an instance of QWSGLPaintDevice, which can
- always return the global static pointer to QOpenGLPaintEngine.
-
- The OpenGL library implementation used for this example only
- supports one OpenGL context. This context is therefore shared
- among the single instance of QAhiGLScreen and all instances of
- QAhiGLWindowSurface. It is passed to both constructors.
-
- This example uses the OpenGL frame buffer object extension, which
- allows for accelerating OpenGL painting operations. Using this
- OpenGL extension, painting operations are performed in a frame
- buffer object, which QAhiGLScreen later uses to construct window
- compositions on the screen. Allocation of the frame buffer object
- is performed in \l {QWindowSurface::} {setGeometry()}. A safer way
- to use this extension would be to first test to see if the
- extension is supported by your OpenGL library, and use a different
- approach if it is not.
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 3
-
- Since there can be several instances of the QAhiGLWindowSurface, we need
- to make sure that the correct framebuffer object is active before painting.
- This is done by reimplementing \l QWindowSurface::beginPaint():
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 4
-
- Finally we need to make sure that whenever a widget grows beyond the size
- supported by this driver (256 x 256), the surface is deleted and a new
- standard surface is created instead. This is handled by reimplementing
- \l QWSWindowSurface::isValid():
-
- \snippet examples/qws/ahigl/qwindowsurface_ahigl.cpp 5
-*/