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
Attachment:
pgpJ2m8rpuG4J.pgp
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel