diff options
| author | Anders Bakken <anders.bakken@nokia.com> | 2009-07-15 17:23:18 (GMT) |
|---|---|---|
| committer | Anders Bakken <anders.bakken@nokia.com> | 2009-07-15 17:44:50 (GMT) |
| commit | c413ae69ae4dc41075f3391fe4838073af657ffb (patch) | |
| tree | 5fd007787ea697a4b7420b3d62a725354c35709e /doc/src/snippets/code/src_qdbus_qdbusreply.cpp | |
| parent | bd6ad2c54ea9bd60ab8dbd5771821ab0e374488e (diff) | |
| download | Qt-c413ae69ae4dc41075f3391fe4838073af657ffb.zip Qt-c413ae69ae4dc41075f3391fe4838073af657ffb.tar.gz Qt-c413ae69ae4dc41075f3391fe4838073af657ffb.tar.bz2 | |
Don't force a lock in QDirectFBPaintEngine::clip
Pretty much every paint operation on DirectFB surfaces starts with
a clipping operations which until now would always cause a
IDirectFBSurface->Lock(). This was to make sure QRasterBuffer::prepare
had been called so QClipData::initialize() would allocate a big enough
array for its spans. We can safely not make
QDirectFBPaintDevice::memory() return 0 until we actually fall back.
Reviewed-By: Donald <qt-info@nokia.com>
Diffstat (limited to 'doc/src/snippets/code/src_qdbus_qdbusreply.cpp')
0 files changed, 0 insertions, 0 deletions