phonon5 and times

[Matěj Laitl]

On 14. 11. 2013 Harald Sitter wrote:
> for phonon5 we can:
> a) keep it and rename it to timeUpdateInterval (to align with rename of
> tick)
> b) drop the interval; always use >=100 msc updates
> c) drop the interval; always use ~100 msc (if VLC is ticking faster
> than that we go <100)
> d) any of b) or c) AND when nothing is connected to timeChanged() no
> ticks will be generated in general == no resources consumption
> (QObject::connectNotify) AND time() does not access cached values but
> will lead to a direct pipeline query
> 
> personally I would go with b+d) as to me those make most sense. by
> default there's a sensible update interval that is not too resource
> consuming. if one wants more precise time values then you'd simply not
> use the builtin timeChanged but use your own QTimer to query time().
> which actually is superior to what we had before because it actually
> encourages avoiding a lot of our abstraction overhead when one wants
> accurate values (calling time() will result in a direct access on the
> pipeline, timeChanged() is a queued and therefore eventloop bound).
> 
> thoughts? opinions?

For Amarok, b+d) would be most sensible.

We're currently setting tickInterval to 100ms and listening to tick() signal, 
but I'd like to change it to do our own QTimer with computed "spatial" 
interval (that we can additionally stop when the window is hidden etc.), 
querying time() each time (assuming it is reasonably precise and cheap in 
order not to introduce flicker).

	Matěj
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia