| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously when an expose was received from WSERV, we simply called
BitBlt (for raster) or called flush on the window surface (for
anything else). This behavior differs from other platforms which call
syncBackingStore(). This difference means that we flush the backing
store without actually updating the content first. This works for most
cases because if there actually was new content, it would be updated
when the widget's UpdateRequest event was handled.
The problem arises when the backing store does not have the correct
content. This can happen if the backing store was deleted, but only
partially restored (see Task below). Another problem is with the OpenVG
graphics system which assumes that beginPaint() is called before
endPaint() is order to initialize the context and the surface size.
The fix is to call syncBackingStore() like the other platforms, but
introduce a bit field to prevent infinite recursion in the painting
pipeline.
Task-number: QTBUG-4921
Reviewed-by: axis
Reviewed-by: Gareth Stockwell
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
| |
QPixmap::copy discarded alpha channel.
This fix also removes usage of member variables CFbsBitGc and
CFbsBitmapDevice. Now those are used only in function scope.
Reviewed-by: Sami Merila
|
|
|
|
|
|
| |
The word 'module' was missing.
Reviewed-By: TrustMe
|
|
|
|
|
|
|
|
|
|
|
|
| |
The crash was caused by the image data not being locked before being
accessed.
Also avoided an unnecessary detach copy by making the image variable
a reference.
RevBy: Jani Hautakangas
Task: QTBUG-4705
AutoTest: QWidget passed
|
|
|
|
|
|
|
|
|
| |
This is done to reduce heap consumption and to give
a possibility to share bitmaps across process. QPixmap
maps to Symbian CFbsBitmap which is stored in Symbian
font and bitmap server.
Reviewed-by: Jason Barron
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
RevBy: Trust me
|
|
|
|
| |
due to http://qt-reviews.europe.nokia.com/r/67/
|
|\
| |
| |
| |
| | |
Conflicts fixed:
src/corelib/io/qdiriterator.cpp
|
| |
| |
| |
| | |
RevBy: Trust me
|
| |
| |
| |
| | |
RevBy: Trust me
|
|/
|
|
| |
compatability
|
|
|
|
|
| |
Contains some smaller fixes and renaming of macros. Looks big,
but isn't scary at all ;)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a window is hidden, it will call releaseBuffer() on the backing
store which in turn will resize the window surface to a null rect. In
this case, there is no need to update the QImage with the data pointer
since it will be updated on the subsequent beginPaint() when the image
is resized to a valid size again. This also avoids doing unnecessary
locking on the FBSERV heap which still involves a context switch on
older versions of Symbian.
|
|
|
|
|
|
|
|
|
| |
This is duplicated code from the raster paint engine's beginPaint()
function. For translucent windows the previous contents must be cleared
from the backing store before the new content is painted. This class
should probably be re-written as a subclass of the raster version. The
reason we cannot use that implementation directly is because we cannot
use QNativeImage because it doesn't provide anywhere we can do locking.
|
|
|
|
|
|
|
|
|
|
|
|
| |
One step closer to semi-transparent windows, but not there yet. This
gets the transparent contents into the window, but the previous
contents are not cleared so it keeps drawing the backing store on top
of itself each time a Draw() is done. SetBackgroundColor() indicates
to WSERV that our window is semi-transparent. We also make sure not to
use 'EDrawModeWriteAlpha' when the widget is non-opaque since this
actually changes the alpha channel on the frame buffer (not the
window) so the gives undesired results. It's a faster draw mode though
so we should use it where we can.
|
|
|
|
|
|
|
|
|
|
|
| |
Warning, this is completely untested!
Details: This should (in theory) get translucent windows working
but this hasn't been tested yet. The emulator environment
seems to return only 16ColorMU display modes which implies
the window is opague so Qt ignores the translucent flag. HW
seems to create 16ColorMA windows, but it hasn't been tested
there yet either (no time).
|
|
|