Phonon design in general

[Matthias Kretz]

On Thursday 28 June 2007, Thierry Bastian wrote:
>  So my idea was to try to focus on reducing the number of classes we have
> in Phonon to the core ones we need. After all Phonon is about having a cool
> cross-platform front-end API to the backends (insanely powerful
> platform-specific multimedia framework).
>
> These are:
>
> -          ObjectDescriptionModel: it is a convenient class that can be
> used to nicely display ObjectDescription to for example choose which effect
> or output audio device to use.
>
> -          BrightnessControl & DeinterlaceFilter: to this point there is
> nothing like that in DirectShow and I wonder if abstracting those effects
> is a really good idea at this point. Directshow gives us the possibility to
> control the brightness and deinterlace but this is only on the video
> renderer. A more abstract way of viewing the effects like it is with the
> enumeration coming from the backend capabilities and and EffectParameter
> makes at this point more sense to me (Note: on Windows by default there is
> no video effect provided by the system)

Those effects are actually expected to be implemented using the renderer. At 
least when all the backend is told to do is to play a video on one 
VideoWidget. As soon as we have something like
MediaObject -> Path -> VideoDataOutput
the brightness and deinterlace effects have to be done in software.

> -          VideoPlayer & AudioPlayer & SeekSlider & VolumeSlider : nice
> things to have but it looks to me there are more like example code than
> really core functionality. They have no interface to the backend.
>
>
>
> This code is all great value to phonon and I think we should not remove it.
> It just makes more sense to have them in a separate “example” directory.
> I’m pretty sure most people won’t use them.

http://lxr.kde.org/ident?i=AudioPlayer
http://lxr.kde.org/ident?i=SeekSlider
VolumeSlider is only used in JuK at this point.

> And if they want to use them, 
> they can still integrate them into their own app (like the
> ObjectDescriptionModel for KCM).

The model I agree to make 100% inline if possible and if it's safe to do that. 
Removing the Player and Slider classes I'm not very happy about.

I just tested the savings of removing VideoPlayer and it's 7532 bytes. 
Removing only the Q_OBJECT macro saves only 36 bytes, removing all public 
slots (keeping Q_OBJECT) saves 28 bytes (this is very impressive!).

If those 50kB really improve the situation on embedded (btw, how big are 
QtCore and QtGui? stripped on my machine they're 1.5MB and 7.6MB) we should 
consider a libphononutils or so. Another candidate for that lib would be 
EffectWidget.

> On my windows machine, removing those classes made the library 20% slimmer
> (248KB down to 196KB). That’s a huge gain (hopefully reproducible with
> ARM).

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/phonon-backends/attachments/20070628/5b816fb4/attachment.pgp