| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Add videorenderer_vmr9.h/cpp back into ds9.pro
Reviewed-by: Justin McPherson
|
| |
|
|
| |
Reviewed-by: Andrew den Exter
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
Warnings are unnecessary when not building for Symbian.
Task-number: QTBUG-9156
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.exe
mkspecs/common/symbian/symbian.conf
src/gui/graphicsview/qgraphicswidget.h
src/gui/kernel/qapplication.cpp
src/gui/text/qtextlayout.cpp
src/openvg/qpixmapdata_vg.cpp
src/s60installs/s60installs.pro
tools/runonphone/main.cpp
tools/runonphone/serenum_unix.cpp
qtextlayout.cpp fixed up together with Eskil.
Kept the configure.exe from 4.7 without recompile.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Symbian^3 introduces a new compositing graphics subsystem in which
non-UI content such as video is provided by client applications via
graphics surfaces.
This patch modifies the video playback part of the Phonon MMF backend
so that, on devices which use the new graphics architecture (NGA),
video is rendered to a surface. On devices which use the legacy
graphics architecture, the existing video rendering path, which uses
Direct Screen Access (DSA) is maintained.
On NGA devices, video playback applications do not deal with surfaces
directly; instead, they use a new MMF client API called
CVideoPlayerUtility2. The implementation of this API takes care of
creating a graphics surface, registering it with the window manager,
and directing the output of the video decoder into this surface.
CVideoPlayerUtility2 inherits from the legacy video playback API,
CVideoPlayerUtility, deprecating certain functions and adding new ones.
The main changes involved in modifying CVideoPlayerUtility client code
to instead use CVideoPlayerUtility2 are:
1. CVideoPlayerUtility requires a window handle to be provided at
object construction time.
The CVideoPlayerUtility2 constructor does not take a window
handle; it is provided by the client later via the
SetDisplayWindowL function.
2. CVideoPlayerUtility requires the client to provide an absolute
screen rectangle at construction time, and then to call
SetDisplayWindowL whenever this rectangle changes due to either
window repositioning or resizing.
CVideoPlayerUtility2 requires the client to provide a display
rectangle which is relative to the display window. This
rectangle must be updated via SetVideoExtentL /
SetWindowClipRectL when the window is resized, but no update is
required when the window is repositioned - the compositing
window system takes care of repositioning the video content on
the screen.
3. CVideoPlayerUtility requires the client to paint transparent
black into the region of the window in which video will be
displayed. CVideoPlayerUtility2 does not require the client
to paint the video window.
In order to accomodate these differences, the existing VideoPlayer and
VideoOutput classes are replaced with AbstractVideoPlayer and
AbstractVideoOutput respectively. These abstract base classes
encapsulate functionality which is common between the DSA and surface
rendering client code. Because CVideoPlayerUtility2 inherits from
CVideoPlayerUtility, AbstractVideoPlayer is able to hold a pointer to
CVideoPlayerUtility, via which it controls functionality which is not
affected by the details of the rendering path, such as play/pause/stop,
seek and metadata access.
The three areas of divergence listed above are encapsulated in the
derived classes DsaVideoOutput/SurfaceVideoOutput and DsaVideoPlayer/
SurfaceVideoPlayer. Of the three, (1) and (3) are fairly
straightforward. For DSA video playback, the need to respond to
changes in video widget absolute screen position in (2) necessitated
the AncestorMoveMonitor class, which installs an event filter on each
ancestor of the video widget. This class is not required for surface
video playback and is therefore removed from the surface-rendering
code path.
Selection of either the DSA- or surface-rendering code path is done
at qmake time, via the exists(...) check introduced in mmf.pro. This
checks for existence of the header in which CVideoPlayerUtility2 is
defined; if this file is found, surface rendering is selected,
otherwise the DSA rendering version of the backend is built. Note that
this approach is not completely robust, since it is possible for an
environment to include the videoplayer2.h header and yet be configured
to use the legacy graphics subsystem. This could be dealt with by
instead performing the check for surface support at configuration time,
building and executing a small Symbian program which will return
different output according to which of the two graphics subsystems is
in use.
Task-number: QTBUG-8919
Reviewed-by: Frans Englich
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
bin/syncqt
doc/src/deployment/deployment.qdoc
src/corelib/io/qfsfileengine_win.cpp
src/corelib/xml/qxmlstream.cpp
src/opengl/gl2paintengineex/qpaintengineex_opengl2_p.h
tools/assistant/tools/assistant/centralwidget.cpp
tools/linguist/lupdate/main.cpp
|
| | |
| |
| |
| |
| | |
Task-number: QTBUG-4659
Reviewed-by: Espen Riskedal
|
| | |
| |
| |
| |
| | |
Task-number: QTBUG-4659
Reviewed-by: Espen Riskedal
|
| | |
| |
| |
| |
| | |
Task-number: QTBUG-4659
Reviewed-by: Espen Riskedal
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change is to work around a limitation in the Phonon::EffectWidget
class. This widget only displays sliders for parameters with numeric
values if the variant type of the parameter is QReal and the range is
exactly -1.0 to +1.0; otherwise, a spinbox is displayed. This is
rather inconvenient for many effects, such as the audio equalizer, for
which a slider is a much more natural UI control.
The MMF backend therefore reports the type of numeric parameters to
be QReal, and the range to be -1.0 to +1.0. Internally, the integer
range for the parameter is stored. Changes to the parameter value are
converted from the client-side, floating point representation to the
internal, integer representation.
Task-number: QTBUG-4659
Reviewed-by: Espen Riskedal
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch addresses the following deficiencies in the existing
implementation of audio effects:
1. Native effect objects (e.g. CAudioEqualizer, CBassBoost etc)
were created frequently, just in order to check whether a given
effect is supported, or retrieve the list of parameters which it
requires. Although this is in part due to a deficiency in the
S60 audio effects API (it doesn't have a 'capability query' concept),
it can be improved by using caching. This patch introduces a
singleton EffectFactory object, which lazily initializes a data
structure containing information about support and parameters.
2. In order to either query effect support, the native effect object
ultimately needs to access a DevSound instance. Previously, the
effect object was provided with a CMdaAudioPlayerUtility object.
If this player utility has not loaded an MMF controller plugin
*before* the effects object makes any calls to the player utility,
incorrect results will be returned. This was observed in the
previous code. For querying, we don't actually need to load an
MMF controller; instead, we would like to directly provide a
CMMFDevSound instance to the effect object. Unfortunately, this
API is not available in public S60 SDKs, so we must use the next
lowest interface available, namely CMdaAudioOutputStream.
By making this change, this patch ensures that support and parameter
queries made via the EffectFactory will return the correct result.
At this point, however, effect settings made via the Phonon API
are not actually applied to the audio output. Fixing this will
require notifying the audio effects backend nodes of state changes
in the MediaObject.
Task-number: QTBUG-4659
Reviewed-by: Espen Riskedal
|
| |\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
doc/src/modules.qdoc
examples/assistant/simpletextviewer/findfiledialog.cpp
examples/webkit/fancybrowser/mainwindow.cpp
src/gui/widgets/qtabbar.cpp
src/gui/widgets/qtabbar_p.h
tests/auto/qpixmap/tst_qpixmap.cpp
tools/assistant/compat/helpdialog.cpp
tools/assistant/compat/tabbedbrowser.cpp
translations/translations.pri
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was introduced by d0b0b525de.
The use of QT_NO_DEBUG macros causes release-armv5 builds to fail
when the -release option is passed to configure.
This change causes the debugging code (ObjectDump and related
classes) to be included in release builds, although these functions
are not executed.
This is a temporary fix; task QTBUG-6012 has been created for
re-removing this code from release builds.
Reviewed-by: Frans Englich
|
| | |
| |
| |
| | |
Reviewed-by: Gareth Stockwell
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Replaced VolumeObserver and VideoOutputObserver interfaces with
signals.
- Added signals for propagating changes in aspect ratio and scale mode
from VideoOutput to VideoPlayer.
- Removed VideoPlayer::getNativeWindowSystemHandles. Interaction with
window system is moved into VideoOutput, so that VideoPlayer is better
focussed on its main task: interacting with CVideoPlayerUtility.
- WId changes, resize and move events received by the VideoOutput
widget cause it to emit a videoWindowChanged signal. This is received
by the VideoPlayer, which triggers a call to updateVideoRect. The
main task of this function is to calculate the scale factors which are
provided to the MMF via CVideoPlayerUtility::SetScaleFactorL. Note
that:
i) This function must be called both before and after the call
to SetDisplayWindowL. For changes in aspect ratio or scale
mode, setting the scale mode after updating the display window
is sufficient. However, testing showed that, when switching in
or out of full-screen mode, two calls were necessary in order
to preserve the correct aspect ratio.
ii) The screen rectangle passed to the MMF is still the full
window extent; it is not the region in which video will
actually be rendered. The post-processor will fill in the
remainder of the window with a background colour (typically
black). If, on the other hand, we passed in the actual video
display rectangle, we would need to do this background painting
in the widget. This in turn would require a change to QtGui:
at present, we can only disable blitting on a per-widget basis
(by setting QWExtra::disableBlit). If we needed to paint the
borders of the video window, disableBlit would need to contain
the actual DSA region, rather than just a single boolean flag.
Task-number: QTBUG-5585
Reviewed-by: Frans Englich
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The debug{} directive in src/plugins/phonon/mmf/plugin/plugin.pro does not have
any effect - this can be seen by looking at the generated MMP file, which has a
STATICLIBRARY directive which is applied in both UDEB and UREL builds. This is
the general problem that .pro files cannot tell distinction between the
different targets that one makespec covers.
Also remove objectdumpstub; objectdump was originally prepared for QtGui
inclusion, but since that never happened, no other platforms than Symbian needs
to be covered.
Task-number: QTBUG-5466
Reviewed-by: Gareth Stockwell
|
| | | |
|
| |/
|
|
|
|
|
|
| |
EVR stands for Enhanced Video Renderer and uses DXVA2. It was
introduced in Windows Vista.
Merge-Request: 1606
Reviewed-By: Thierry
|
| |
|
|
|
| |
Task-number: QTBUG-4662
Reviewed-by: Frans Englich
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Phonon.
Both epoc32/include and $QTDIR/include/Phonon contain a file called videoplayer.h. Both of these directories are listed as SYSTEMINCLUDE paths in the generated MMP file, with the Phonon path coming first. This means that '#include <videoplayer.h>' picks up the Phonon header rather than (as intended) the Symbian one.
A new qmake variable, PREPEND_INCLUDEPATH, is defined, allowing the .pro file to specify that /epoc32/include should be the first SYSTEMINCLUDE.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
In any case, we haven't implemented this effect.
|
| |
|
|
| |
MW_LAYER_SYSTEMINCLUDE macro
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| | |
mmfphonon
|
| | | |
|
| |/
|
|
|
|
| |
- Forward declaration of QScopedPointer containee type was causing an error
- Audio effect libraries were declared in the .pro file as e.g. -lBassBoostEffect.lib, causing toolchain to try to link statically
- Added several missing MMF:: namespace qualifiers
|
| |
|
|
| |
5.0 environment
|
| |
|
|
|
|
|
|
|
| |
This extends the framework for being able to handle audio effects, largely
affecting how the audio chain is set up, connected and disconnected, and
therefore the Backend has been refactored slightly, and the class MediaNode
introduced, see its documentation.
In addition two effects has been written: BassBoost and AudioEqualizer.
|
| | |
|
| | |
|
| |
|
|
| |
Symbian control / window associated with each widget
|
| |
|
|
| |
VideoPlayer
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
and AudioOutput
|
| |\ |
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/itemviews/qitemselectionmodel.cpp
tests/auto/qitemselectionmodel/tst_qitemselectionmodel.cpp
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On the Mac, it means "-framework ApplicationServices -framework Carbon
-framework AppKit" are no longer part of the default LIBS in Qt
applications. This required a lot of fixes where we used Mac-specific
code in Qt.
On X11, it was very straightforward, because we apparently use very
little of X11 outside QtGui.
I haven't changed the Windows-specific LIBS paths, because I don't
know how Windows behaves. Windows has DLLs, but it links to static
"import" libraries. So is it static linking or dynamic linking?
Reviewed-By: Marius Storm-Olsen
|
| | | |
|
