diff options
author | Gareth Stockwell <gareth.stockwell@sosco.com> | 2009-09-18 17:18:38 (GMT) |
---|---|---|
committer | Frans Englich <frans.englich@nokia.com> | 2009-09-23 12:39:41 (GMT) |
commit | da4e047c7bcf6dc966dcb862033ce8c09bd561d9 (patch) | |
tree | 333adc7c2e72a450efed0e1f336822a2f093e71e /src/3rdparty/libjpeg/makefile.wat | |
parent | be44bb7e43c76305133b09918c3ad8d3f9b2bed5 (diff) | |
download | Qt-da4e047c7bcf6dc966dcb862033ce8c09bd561d9.zip Qt-da4e047c7bcf6dc966dcb862033ce8c09bd561d9.tar.gz Qt-da4e047c7bcf6dc966dcb862033ce8c09bd561d9.tar.bz2 |
Experimenting to make video visible.
Removed the hack to set translucent window background in the mediaplayer.
Then tried the following:
1. Direct write to backing store: does not work (backing bitmap is 16MU)
2. Set window background color: does not work (is over-written by control's Draw function)
3. Brush using CWindowGc from widget's paint event: does not work (is over-written by control's Draw function)
4. Hack QSymbianControl to blit a transparent bitmap from the Draw function: does work
5. Hack QSymbianControl to brush using CWindowGc from the Draw function: does work
Configuration 5 is the one being committed.
Other things we could try:
6. Trigger switch to 16MA backing store if child widgets have been created. This could be tested by calling RWindowTreeNode::Child on the TLW's window.
- Maybe we could test whether the child window's display mode is 16MA?
7. Somehow tell QSymbianControl not to draw anything at all
- Based on setting Qt::WA_PaintOnScreen?
- Then we either:
- (Ideally) do nothing, and rely on video stack to paint the necessary transparency
- Brush using CWindowGc from widget's paint event
Diffstat (limited to 'src/3rdparty/libjpeg/makefile.wat')
0 files changed, 0 insertions, 0 deletions