| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
