From fbbdf8698fb0444d5170b7d0a14e870ea789398f Mon Sep 17 00:00:00 2001 From: Morten Engvoldsen Date: Thu, 19 Nov 2009 14:32:27 +0100 Subject: Doc: Adding documentation on Embedded Hardware acceleration Added "best practice" page on HW acc for mebedded. Modified HW acc docs. Adding Hello GL ES for Wince to the list of examples. QTBUG-5791 David Boddie --- doc/src/getting-started/examples.qdoc | 1 + doc/src/howtos/HWacceleration.qdoc | 100 ++++++++ doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc | 62 +++-- doc/src/platforms/emb-HwAcc-WinCE.qdoc | 1 - doc/src/platforms/emb-hardwareacceleration.qdocinc | 269 +++++++++++---------- 5 files changed, 289 insertions(+), 144 deletions(-) create mode 100644 doc/src/howtos/HWacceleration.qdoc diff --git a/doc/src/getting-started/examples.qdoc b/doc/src/getting-started/examples.qdoc index b5dc03d..e951804 100644 --- a/doc/src/getting-started/examples.qdoc +++ b/doc/src/getting-started/examples.qdoc @@ -794,6 +794,7 @@ \o \l{opengl/framebufferobject2}{Framebuffer Object 2} \o \l{opengl/grabber}{Grabber} \o \l{opengl/hellogl}{Hello GL}\raisedaster + \o \l{opengl/hellogl_es}{Hello GL - ported to Windows CE}\raisedaster \o \l{opengl/overpainting}{Overpainting}\raisedaster \o \l{opengl/pbuffers}{Pixel Buffers} \o \l{opengl/pbuffers2}{Pixel Buffers 2} diff --git a/doc/src/howtos/HWacceleration.qdoc b/doc/src/howtos/HWacceleration.qdoc new file mode 100644 index 0000000..80db740 --- /dev/null +++ b/doc/src/howtos/HWacceleration.qdoc @@ -0,0 +1,100 @@ +/**************************************************************************** +** +** 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$ +** +****************************************************************************/ + +/*! + \page HWAcc_rendering.html + \title Using hardware acceleration on embedded platforms. + + \ingroup best-practices + + \section1 Abstract + This document describes how to use hardware acceleration for fast + rendering on embedded platforms supported by Qt. In short, it explains + how the graphics pipeline works. Since there might be differences to + how the APIs are being used on different embedded platforms, a table + links to documentation dedicated to platform specific documentation + for each supported hardware acceleration API. + + \input platforms/emb-hardwareacceleration.qdocinc + + \section1 Supported platforms + Since there might be differences to how the APIs are being used on + the different embedded platforms, this table provides you with links to + pages dedicated to platform specific documentation for each + supported hardware acceleration API. Click the API link for the + platform to go the correct documentation. + + \table + \header + \o Operating System + \o {3,1} Hardware Acceleration Platform + \row + \o \bold {Windows CE} + \o \l {Qt for Windows CE and OpenGL ES}{OpenGL ES} + \o \l {Qt for Windows CE and OpenVG}{OpenVG} + \o + \row + \o \bold {Embedded Linux} + \o \l {Qt for Embedded Linux and OpenGL}{OpenGL ES} + \o \l {Qt for Embedded Linux and OpenVG}{OpenVG} + \o \l {Qt for Embedded Linux and DirectFB}{DirectFB} + \row + \o \bold {Symbian Platform} + \o {3,1} \e {There are currently no support for hardware + acceleration.} + \endtable +\omit + \section1 Examples using hardware acceleration on embedded platforms. + + \table + \header + \o Embedded Platform + \o Example + \row + \o Windows CE + \row + \o Embedded Linux + \endtable +\endomit + + + +*/ diff --git a/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc b/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc index 9c18d87..a9bd167 100644 --- a/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc +++ b/doc/src/platforms/emb-HwAcc-LinuxEmbedded.qdoc @@ -49,23 +49,57 @@ \ingroup qt-embedded-linux - \input platforms/emb-hardwareacceleration.qdocinc + \input platforms/emb-hardwareacceleration.qdocinc -\section1 Supported Hardware Accelerated Graphics APIs + \section1 Windowing on Embedded Linux with Hardware Accelerated Graphics -This list shows which Hardware Accelerated Graphics APIs currently -supported by Qt. + Qt for Embedded Linux includes its own windowing system, QWS. QWS was + designed in 1999, well before graphics acceleration was available for + embedded devices. It does a great job providing a lightweight window + manager including all the expected functionality such as arbitrary + windows that can be moved, resized, minimized, etc. Getting QWS to work + with GPUs is very challenging, particularly with OpenGL and OpenVG + because there is no standard way in Linux to share textures across + processes. Some silicon vendors provide private APIs to allow texture + sharing, others do not. These limitations are documented under the + sections describing each type of accelerated hardware APIs. The simplest + most generic support for accelerated graphics is a full screen single + process single window. - \table - \header - \o Supported Hardware Accelerated Graphics APIs - \row - \o \l {Qt for Embedded Linux and OpenGL}{OpenGL ES} - \row - \o \l {Qt for Embedded Linux and OpenVG}{OpenVG} - \row - \o \l {Qt for Embedded Linux and DirectFB}{DirectFB} - \endtable + \section2 General options + \list + \o QWS, not accelerated, allows arbitrary windowing with multiple + processes drawing on the screen. + \o X11 with an accelerated X11 driver provided by the silicon + vendor. Like QWS, this allows arbitrary windows with multiple + processes drawing on the screen. Our experience is that there is + some overhead from X11 which will adversely affect framerates. + Additionally, our experience is that the drivers from silicon + vendors are still maturing. + \o Full screen single process single window. This will always work. + Some additional capabilities are available and are documented in + the acceleration specific API sections. + \endlist + + \section1 Supported Hardware Accelerated Graphics APIs + + This table shows which Hardware Accelerated Graphics APIs currently + supported by Qt. + + \table + \header + \o Supported APIs + \o API Version + \row + \o \l {Qt for Embedded Linux and OpenGL}{OpenGL ES} + \o 1.x and 2.x + \row + \o \l {Qt for Embedded Linux and OpenVG}{OpenVG } + \o 1.1 + \row + \o \l {Qt for Embedded Linux and DirectFB}{DirectFB} + \o 2.0 + \endtable */ diff --git a/doc/src/platforms/emb-HwAcc-WinCE.qdoc b/doc/src/platforms/emb-HwAcc-WinCE.qdoc index 66b6948..b7789f1 100644 --- a/doc/src/platforms/emb-HwAcc-WinCE.qdoc +++ b/doc/src/platforms/emb-HwAcc-WinCE.qdoc @@ -47,7 +47,6 @@ \title Qt for Windows CE Hardware Accelerated Graphics \ingroup qtce - \input platforms/emb-hardwareacceleration.qdocinc \section1 Supported Hardware Accelerated Graphics APIs diff --git a/doc/src/platforms/emb-hardwareacceleration.qdocinc b/doc/src/platforms/emb-hardwareacceleration.qdocinc index 3851628..fb00e09 100644 --- a/doc/src/platforms/emb-hardwareacceleration.qdocinc +++ b/doc/src/platforms/emb-hardwareacceleration.qdocinc @@ -1,129 +1,140 @@ - -\section1 Hardware Acceleration - -When designing applications for embedded devices the choice often stands -between graphics effects and performance. On most devices, you cannot have -both simply because the hardware needed for such operations just is not -there. Still a growing number of devices use hardware dedicated to graphics -operations to improve performance. - -Using graphics acceleration hardware is more power efficient than using the -CPU. The reason for this is that the CPU might require a clock speed that -is up to 20 times higher than the GPU, achieving the same results. E.g. a -typical hardware accelerated mobile graphics unit can rasterize one or two -bilinear texture fetches in one cycle, while a software implementation -takes easily more than 20 cycles. Graphics hardware generally have a much -lower clock speed and memory bandwidth and different level of acceleration -than desktop GPUs. One example is that many GPUs leave out transformation -and lighting from the graphics pipeline and only implements rasterization. - -So the key to write good applications for devices is therefore to limit the -wow factor down to what the target hardware can handle, and to take -advantage of any graphics dedicated hardware. Qt provides several ways to -both render advanced effects on the screen and speed up your application -using hardware accelerated graphics. - -\tableofcontents - -\section2 Qt for Embedded Graphics pipeline - -Qt uses QPainter for all graphics operations. By using the same API -regardless of platform, the code can be reused on different devices. -QPainter use different paint engines implemented in the QPaintEngine API to -do the actual painting. - -The QPaintEngine API provides paint engines for each window system and -painting framework supported by Qt. In regards to Qt for Embedded, this -also includes implementations for OpenGL ES versions 1.1 and 2.0, as well -as OpenVG and DirectFB(Embedded Linux only). - -By using one of these paint engines, you will be able to improve the -graphics performance of your Qt application. However, if the graphics -operations used are not supported, this might as well be a trap, slowing -down your application significantly. This all depends on what kind of -graphics operations that are supported by the target devices hardware -configuration. - -\image platformHWAcc.png - -The paint engine will direct all graphics operations supported by the -devices hardware to the GPU, and from there they are sent to the -framebuffer. Unsupported graphics operations falls back to the -QRasterPaintEngine and are handled by the CPU before sent to the -framebuffer. In the end, the operating system sends the paint updates off -to the screen/display. The fallback operation is quite expensive in regards -to memory consumption, and should be avoided. - -\section2 Hardware configuration requirements - -Before implementing any application using hardware acceleration, it is wise -to get an overview of what kind of hardware accelerated graphics operations -that are available for the target device. - -\note On devices with no hardware acceleration, Qt will use -QRasterPaintEngine, which handles the acceleration using software. On -devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows -CE), Qt will use the -respective paint engines to accelerate painting. However, hardware -configurations that only support a limited set of hardware acceleration -features, might slow the application graphics down rather than speeding it -up when using unsupported operations that must fall back to the raster -engine. - -\section3 Different architectures - -Based on the architecture used in a device we can make a recommendation on -which hardware acceleration techniques to use. There are mainly two -different architectures on embedded devices. These are devices with a -Unified Memory Architecture (UMA), and devices with dedicated graphics -memory. Generally, high-end devices will have dedicated graphics memory. -Low-end devices will just use system memory, sometimes reserving a memory -region and sometimes not. - -In addition to this, we can categorize the devices into five types based on -the different graphics operations supported by their hardware. - -\list 1 - \o No support for graphics acceleration. - \o Support for blitter and alpha blending. - \o Support for path based 2D vector graphics. - \o Support for fixed function 3D graphics. - \o Support for programmable 3D graphics. -\endlist - -Based on these characteristics the table below recommends which paint -engines to use with the different types of hardware configurations. - -\section3 Recommended use of hardware acceleration based on hardware - - \table - \header - \o Type - \o UMA - \o Non-UMA - \row - \o \bold {None} - \o Qt Raster Engine - \o Qt Raster Engine - \row - \o \bold {Blitter} - \o DirectFB - \o DirectFB - \row - \o \bold {2D Vector} - \o OpenVG - \o OpenVG - \row - \o \bold {Fixed 3D} - \o OpenGL (ES) 1.x - \o OpenGL (ES) 1.x - \row - \o \bold {Programmable 3D} - \o OpenGL (ES) 2.x - \o OpenGL (ES) 2.x - - \endtable - -\note Since the DirectFB API is quite primitive, the raster paint engine -handles most of the operations. -\note Blitter and Alpha blending is currently not supported on Windows CE. + \section1 Hardware Acceleration + + When designing applications for embedded devices there is often a + compromise between graphics effects and performance. On most + devices, you cannot have both simply because the hardware needed + for such operations just is not there. With a growing number of + devices that use hardware dedicated to graphics operations there is + less need to compromise. + + In addition to enabling dynamic graphics effects, there are two + other benefits to using graphics acceleration. One is that graphics + acceleration hardware is more power efficient than using the CPU. + The reason for this is that the CPU might require a clock speed + that is up to 20 times higher than the GPU, achieving the same + results. E.g. a typical hardware accelerated mobile graphics unit + can rasterize one or two bilinear texture fetches in one cycle, + while a software implementation takes easily more than 20 cycles. + Typical \e {System-on-a-chip} (SoC) graphics hardware generally have + a much lower clock speed and memory bandwidth, and different level + of acceleration than desktop GPUs. One example is that many GPUs + leave out transformation and lighting from the graphics pipeline + and only implements rasterization. + + Another reason to use a GPU is to offload the main CPU, either for + power saving or to perform other operations in parallel. Often + drawing speed with a GPU is not that much faster than a CPU but + the clear benefit of using the GPU is to free up the CPU to perform + other tasks which can be used to create a more responsive use + experience. + + The key to writing good applications for devices is therefore to + limit the wow factor down to what the target hardware can handle, + and to take advantage of any graphics dedicated hardware. Qt + provides several ways to both render advanced effects on the screen + and speed up your application using hardware accelerated graphics. + + \tableofcontents + + \section2 Qt for Embedded Graphics pipeline + + Qt uses QPainter for all graphics operations. By using the same API + regardless of platform, the code can be reused on different devices. + QPainter use different paint engines implemented in the QPaintEngine API to + do the actual painting. + + The QPaintEngine API provides paint engines for each window system and + painting framework supported by Qt. In regards to Qt for Embedded, this + also includes implementations for OpenGL ES versions 1.1 and 2.0, as well + as OpenVG and DirectFB(Embedded Linux only). + + By using one of these paint engines, you will be able to improve the + graphics performance of your Qt application. However, if the graphics + operations used are not supported, this might as well be a trap, slowing + down your application significantly. This all depends on what kind of + graphics operations that are supported by the target devices hardware + configuration. + + \image platformHWAcc.png + + The paint engine will direct all graphics operations supported by the + devices hardware to the GPU, and from there they are sent to the + framebuffer. Unsupported graphics operations falls back to the + QRasterPaintEngine and are handled by the CPU before sent to the + framebuffer. In the end, the operating system sends the paint updates off + to the screen/display. The fallback operation is quite expensive in regards + to memory consumption, and should be avoided. + + \section2 Hardware configuration requirements + + Before implementing any application using hardware acceleration, it is wise + to get an overview of what kind of hardware accelerated graphics operations + that are available for the target device. + + \note On devices with no hardware acceleration, Qt will use + QRasterPaintEngine, which handles the acceleration using software. On + devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows + CE), Qt will use the + respective paint engines to accelerate painting. However, hardware + configurations that only support a limited set of hardware acceleration + features, might slow the application graphics down rather than speeding it + up when using unsupported operations that must fall back to the raster + engine. + + \section3 Different architectures + + Based on the architecture used in a device we can make a recommendation on + which hardware acceleration techniques to use. There are mainly two + different architectures on embedded devices. These are devices with a + Unified Memory Architecture (UMA), and devices with dedicated graphics + memory. Generally, high-end devices will have dedicated graphics memory. + Low-end devices will just use system memory, sometimes reserving a memory + region and sometimes not. + + In addition to this, we can categorize the devices into five types based on + the different graphics operations supported by their hardware. + + \list 1 + \o No support for graphics acceleration. + \o Support for blitter and alpha blending. + \o Support for path based 2D vector graphics. + \o Support for fixed function 3D graphics. + \o Support for programmable 3D graphics. + \endlist + + Based on these characteristics the table below recommends which paint + engines to use with the different types of hardware configurations. + + \section3 Recommended use of hardware acceleration based on hardware + + \table + \header + \o Type + \o UMA + \o Non-UMA + \row + \o \bold {None} + \o Qt Raster Engine + \o Qt Raster Engine + \row + \o \bold {Blitter} + \o DirectFB + \o DirectFB + \row + \o \bold {2D Vector} + \o OpenVG + \o OpenVG + \row + \o \bold {Fixed 3D} + \o OpenGL (ES) 1.x + \o OpenGL (ES) 1.x + \row + \o \bold {Programmable 3D} + \o OpenGL (ES) 2.x + \o OpenGL (ES) 2.x + \endtable + + \note Since the DirectFB API is quite primitive, the raster paint engine + handles most of the operations. + + \note Blitter and Alpha blending is currently not supported on Windows CE. -- cgit v0.12 From 51b3c2e652578f5577c07c22e177699d345c1dd7 Mon Sep 17 00:00:00 2001 From: Martin Smith Date: Thu, 19 Nov 2009 15:24:40 +0100 Subject: doc: Added note about including a 3rd party library in the bundle. --- doc/src/deployment/deployment.qdoc | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/doc/src/deployment/deployment.qdoc b/doc/src/deployment/deployment.qdoc index b5b1b9c..f94dde1 100644 --- a/doc/src/deployment/deployment.qdoc +++ b/doc/src/deployment/deployment.qdoc @@ -1490,7 +1490,13 @@ \o Accessibility for Qt3Support is deployed if the application uses the Qt3Support module. \endlist - macdeployqt supports the following options: + \note If you want a 3rd party library to be included in your + application bundle, then you must add an excplicit lib entry for + that library to your application's .pro file. Otherwise, the + \c macdeployqt tool will not copy the 3rd party .dylib into the + bundle. + + \c macdeployqt supports the following options: \list \o -no-plugins: Skip plugin deployment \o -dmg : Create a .dmg disk image -- cgit v0.12 From b752acf1805eebd64e7e833862690e9ebdb714e3 Mon Sep 17 00:00:00 2001 From: Volker Hilsheimer Date: Thu, 19 Nov 2009 17:04:01 +0100 Subject: Document known issue - window resizing slower on Windows 7 due to gesture initialization process creating window handles. --- doc/src/getting-started/known-issues.qdoc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/src/getting-started/known-issues.qdoc b/doc/src/getting-started/known-issues.qdoc index 5c8888d..0af432d 100644 --- a/doc/src/getting-started/known-issues.qdoc +++ b/doc/src/getting-started/known-issues.qdoc @@ -122,6 +122,11 @@ \o A bug in the Firebird database can cause an application to crash when \c{fbembed.dll} is unloaded. The bug is fixed in version 2.5. + \o On Windows 7, resizing windows is slower than on Vista/Xp. This is because + the gesture initialization process (required for native gesture support) + currently calls winId() on widgets, which causes whole widget hierarchies + to use native window handles. This slows down resizing. + \endlist \section2 Mac OS X -- cgit v0.12 From 34dbd7b720875e4e266beee66f6f41e624ea5aad Mon Sep 17 00:00:00 2001 From: Andre Pedralho Date: Thu, 19 Nov 2009 17:15:38 +0100 Subject: Updated the 'framecapture' WebKit example according to WebKit API changes. Merge-request: 2142 Reviewed-by: Simon Hausmann --- examples/webkit/framecapture/framecapture.cpp | 5 ++--- examples/webkit/framecapture/main.cpp | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/examples/webkit/framecapture/framecapture.cpp b/examples/webkit/framecapture/framecapture.cpp index 2c2e11b..4636b8d 100644 --- a/examples/webkit/framecapture/framecapture.cpp +++ b/examples/webkit/framecapture/framecapture.cpp @@ -59,6 +59,7 @@ void FrameCapture::load(const QUrl &url, const QString &outputFileName) m_page.mainFrame()->load(url); m_page.mainFrame()->setScrollBarPolicy(Qt::Vertical, Qt::ScrollBarAlwaysOff); m_page.mainFrame()->setScrollBarPolicy(Qt::Horizontal, Qt::ScrollBarAlwaysOff); + m_page.setViewportSize(QSize(1024, 768)); } void FrameCapture::printProgress(int percent) @@ -88,8 +89,6 @@ void FrameCapture::saveResult(bool ok) int index = m_fileName.lastIndexOf('.'); fileName = fileName.insert(index, "_frame" + QString::number(++frameCounter)); - frame->setClipRenderToViewport(false); - QImage image(frame->contentsSize(), QImage::Format_ARGB32_Premultiplied); image.fill(Qt::transparent); @@ -112,7 +111,7 @@ void FrameCapture::saveFrame(QWebFrame *frame, QImage image, QString fileName) painter.setRenderHint(QPainter::TextAntialiasing, true); painter.setRenderHint(QPainter::SmoothPixmapTransform, true); - frame->render(&painter); + frame->documentElement().render(&painter); painter.end(); diff --git a/examples/webkit/framecapture/main.cpp b/examples/webkit/framecapture/main.cpp index 050947a..65c0026 100644 --- a/examples/webkit/framecapture/main.cpp +++ b/examples/webkit/framecapture/main.cpp @@ -63,7 +63,7 @@ int main(int argc, char * argv[]) return 0; } - QUrl url = QWebView::guessUrlFromString(QString::fromLatin1(argv[1])); + QUrl url = QUrl::fromUserInput(QString::fromLatin1(argv[1])); QString fileName = QString::fromLatin1(argv[2]); QApplication a(argc, argv); -- cgit v0.12 From 45e49fc7a325855c6eafa83b85f5ddfdf793c118 Mon Sep 17 00:00:00 2001 From: Andre Pedralho Date: Thu, 19 Nov 2009 17:15:39 +0100 Subject: Fixing the frame hierarchy traversing in framecapture WebKit example. Merge-request: 2142 Reviewed-by: Simon Hausmann --- examples/webkit/framecapture/framecapture.cpp | 37 ++++++++++++--------------- examples/webkit/framecapture/framecapture.h | 2 +- 2 files changed, 18 insertions(+), 21 deletions(-) diff --git a/examples/webkit/framecapture/framecapture.cpp b/examples/webkit/framecapture/framecapture.cpp index 4636b8d..ef49e93 100644 --- a/examples/webkit/framecapture/framecapture.cpp +++ b/examples/webkit/framecapture/framecapture.cpp @@ -82,39 +82,36 @@ void FrameCapture::saveResult(bool ok) return; } - // save each internal frame in different image files - int frameCounter = 0; - foreach(QWebFrame *frame, m_page.mainFrame()->childFrames()) { - QString fileName(m_fileName); - int index = m_fileName.lastIndexOf('.'); - fileName = fileName.insert(index, "_frame" + QString::number(++frameCounter)); + // save each frame in different image files + saveFrame(m_page.mainFrame()); - QImage image(frame->contentsSize(), QImage::Format_ARGB32_Premultiplied); - image.fill(Qt::transparent); + emit finished(); +} - saveFrame(frame, image, fileName); +void FrameCapture::saveFrame(QWebFrame *frame) +{ + static int frameCounter = 0; + + QString fileName(m_fileName); + if (frameCounter) { + int index = m_fileName.lastIndexOf('.'); + fileName = fileName.insert(index, "_frame" + QString::number(frameCounter)); } - // save the main frame - m_page.setViewportSize(m_page.mainFrame()->contentsSize()); - QImage image(m_page.mainFrame()->contentsSize(), QImage::Format_ARGB32_Premultiplied); + QImage image(frame->contentsSize(), QImage::Format_ARGB32_Premultiplied); image.fill(Qt::transparent); - saveFrame(m_page.mainFrame(), image, m_fileName); - emit finished(); -} - -void FrameCapture::saveFrame(QWebFrame *frame, QImage image, QString fileName) -{ QPainter painter(&image); painter.setRenderHint(QPainter::Antialiasing, true); painter.setRenderHint(QPainter::TextAntialiasing, true); painter.setRenderHint(QPainter::SmoothPixmapTransform, true); - frame->documentElement().render(&painter); - painter.end(); image.save(fileName); + + ++frameCounter; + foreach(QWebFrame *childFrame, frame->childFrames()) + saveFrame(childFrame); } diff --git a/examples/webkit/framecapture/framecapture.h b/examples/webkit/framecapture/framecapture.h index 9de9c43..7a6d5f3 100644 --- a/examples/webkit/framecapture/framecapture.h +++ b/examples/webkit/framecapture/framecapture.h @@ -64,7 +64,7 @@ private: QString m_fileName; int m_percent; - void saveFrame(QWebFrame *frame, QImage image, QString fileName); + void saveFrame(QWebFrame *frame); }; #endif -- cgit v0.12 From 095c92f03e0c01b878eaa0cd1b7844171ce9241f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20Abecasis?= Date: Thu, 19 Nov 2009 17:15:03 +0100 Subject: Revert check for file size to a warning in QFile::map The check, introduced in c66de8a19b558e14097c402480eeabf0b5ec2351, changes behavior and it is not clear whether we should prevent mmaping beyond EOF. FWIW, python prevents it. Leaving a warning in there for now so as not to break applications that depend on the feature. Task-number: QTBUG-6008 Reviewed-by: Thiago Macieira --- src/corelib/io/qfsfileengine_unix.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/corelib/io/qfsfileengine_unix.cpp b/src/corelib/io/qfsfileengine_unix.cpp index 05e6fab..35737b3 100644 --- a/src/corelib/io/qfsfileengine_unix.cpp +++ b/src/corelib/io/qfsfileengine_unix.cpp @@ -1254,7 +1254,7 @@ uchar *QFSFileEnginePrivate::map(qint64 offset, qint64 size, QFile::MemoryMapFla // undefined behavior. Otherwise, let mmap have its say. if (doStat() && (QT_OFF_T(size) > st.st_size - QT_OFF_T(offset))) - return 0; + qWarning("QFSFileEngine::map: Mapping a file beyond its size is not portable"); int access = 0; if (openMode & QIODevice::ReadOnly) access |= PROT_READ; -- cgit v0.12