[Spice-devel] [PATCH spice] RFC: remove guest side video time-stamping

[Christophe Fergeau]

On Tue, Nov 04, 2014 at 10:00:06AM -0500, Marc-André Lureau wrote:
> 
> 
> ----- Original Message -----
> > Hey,
> > 
> > On Sun, Nov 02, 2014 at 10:24:13PM +0100, Marc-André Lureau wrote:
> > > The multimedia time is defined by the server side monotonic time [1],
> > > but the drawing time-stamp is done in guest side, so it requires
> > > synchronization between host and guest. This is expensive, when no audio
> > > is playing, there is a ~30x/sec wakeup to update the qxl device mmtime,
> > > and it requires marking dirty the rom region.
> > 
> > I guess this could be used somehow to detect when images are taking a
> > long time to get drawn in the guest, but doing things the way they
> > currently are does not seem to be useful indeed.
> 
> I think it would be wrong to rely on the server/QXL timestamp to do
> this, there is probably a better clock for that.

Not saying it's right or wrong, I'm only trying to understand why things
were made this way.

> 
> > > 
> > > Instead, the video timestamping can be done more efficiently on server
> > > side, without visible drawbacks.
> > 
> > I think this could go a step further, and mm_time could be set as below
> > rather than
> > in process_commands. Maybe RedDrawable::mm_time could even be removed.
> 
> Marshalling time is when the command is actually sent to client, not the time it is "drawn" by guest.

Ah right.
The main reason I was mentioning that is that modifying the RedDrawable
in red_process_drawable() feels a bit out of place. Maybe it would be
better in red_get_compat_drawable()/red_get_native_drawable()? (this way
it's more obvious we are not using mm_time from the guest).

If nobody objects, you should send a non-RFC patch ;)

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20141104/e87e90f0/attachment.sig>