| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being moved.
Because QWidget::moveEvent is only called when a widget moves relative
to its parent, a widget's absolute screen position may change without it
receiving a moveEvent (for example, as a result of its parent being
moved).
The MMF video playback API on Symbian v9.4 requires, in addition to a
window handle, an absolute screen rectangle. Changes in the video
widget's absolute screen position therefore need to be propagated
into the MMF.
This change introduces a new object, AncestorMoveMonitor, which
installs an event filter on the QCoreApplication instance. A
VideoOutput object registers with the AncestorMoveMonitor, which
listens on its behalf for MoveEvents and ParentChangeEvents directed
at any of the ancestors of the VideoOutput. MoveEvents trigger a
callback to the VideoOutput instance, which then notifies the MMF of
the new screen rectangle. ParentChangeEvents cause the
AncestorMoveMonitor to update the ancestor list associated with the
target VideoOutput instance.
The video position now tracks that of the associated widget, but there
are two problems which require further investigation:
1. The video window lags behind. This may be an unavoidable
consequence of the fact that setting a new screen rectangle causes the
MMF to tear down its DSA session and start a new one; this is known to
block the window server and take some time to complete.
2. Artifacts are visible around the edges of the moving video widget.
Task-number: QTBUG-4787
Reviewed-by: Frans Englich
|
| |
|
|
|
| |
sed -i -e 's/\t/ /g' `find -name "*.cpp" -or -name "*.h" -or -name
"*.pro"`
|
| |
|
|
| |
"*.pro"`
|
| | |
|
| |
|
|
|
| |
Task-number: QTBUG-4664
Reviewed-by: Frans Englich
|
| |
|
|
|
|
| |
Moved common code into videoOutputRegionChanged()
Reviewed-by: Frans Englich
|
| | |
|
| |
|
|
| |
This reverts commit 1062bbbcd6c30844d9ade10de80f27a3afd4dacf.
|
| | |
|
| |
|
|
| |
Addresses review comment.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
| |
for testing
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Symbian control / window associated with each widget
|
| |\
| |
| |
| | |
mmfphonon
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
out)
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
| |
VideoPlayer
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
no effect at present
|
| |
|
|
|
| |
Video is still not visible; need to debug the initialization of the
VideoOutput object to determine whether DSA is being aborted.
|
| |
|
