| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
| |
See VideoOutput::transparentFill. This should be called from the paintEvent, having removed the TranslucentWindowBackground hack from the mediaplayer demo.
As yet this has not been tested.
|
| |
|
|
| |
This is useful when debugging problems with the interaction between video rendering, Qt widget rendering and the underlying native control / window system.
|
| |
|
|
| |
Symbian control / window associated with each widget
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
VideoPlayer
|
| |
|
|
|
|
|
|
| |
This was causing the stateChanged signal not to propagate up to the Phonon client. In the case of the mediaplayer demo, this causes the app not to show() the ancestor of the VideoWidget, resulting in the layout not being updated when the clip has been loaded.
This means that the hack to explicitly call show() on this ancestor from the backend has been removed.
Now the layout is correctly updated, but the size of VideoOutput::winId()->Rect() is still incorrect, so the hack to hard-code the screen rectangle passed to CVideoPlayerUtility is left in place.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These hacks, which are enabled using macros in defs.h, are:
PHONON_MMF_HARD_CODE_VIDEO_RECT
VideoPlayer should obtain the screen rectangle into which video rendering will occur, using the CoeControl associated with the video widget (i.e. the VideoOutput object). However, this control always has co-ordinates (relative to its parent) of (0,0)-(100,30), regardless of whether updateGeometry() and show() are called on the widget. So, this macro just hard-codes the screen rectangle to a value which works when the breakfast.mp4 clip is used for testing.
PHONON_MMF_EXPLICITLY_SHOW_VIDEO_WIDGET
In order that the video region does not overwrite the slider and buttons below it, the parent widget of the VideoObject instance must be appropriately re-sized. Debugging showed that both the parent and grandparent of VideoObject are in fact invisible at the time playback begins, so for now we just manually call show() on the grandparent.
Clearly both of these are only temporary measures, for use until the underlying cause of the problem has been determined.
|
| | |
|
| | |
|
| |
|
