[Spice-devel] xf86-video-qxl performance

[Alon Levy]

On Wed, May 23, 2012 at 10:02:03PM -0400, Marc-André Lureau wrote:
> Hi
> 
> ----- Mensaje original -----
> > Also, as a crazy idea, has anyone considered implementing a pure
> > streaming video driver?  That is, what if we had a frame buffer
> > driver,
> > and then a thread that fired 29 times a second to drive a theora or
> > vp8
> > encoder, simply feeding the current frame at those intervals.

The idea is not crazy at all. On the todo list.

> 
> Even if doable, using theora or vp8 would result in poor visual quality
> that isn't really acceptable for desktops.
> 
> Although there are some screencast video codecs (microsoft a developped
> several over the years, unfortunately, there aren't very well known, and
> I wonder how they differ from some kind of saved rdp stream)

I couldn't find any codec that was opened last time I searched.

> 
> However, I haven't look much at optimization, but I can imagine it
> could be interesting to combine drawing operation more aggressively
> perhaps based on a timer too (I don't think we do it, but I know that we
> do some combining in some cases when the sending queue is full).

No, what we do is combine some operations (change/drop) by looking at
current outstanding messages (queued but not yet sent - in the pipe)
whenever we read a new message from the device (from the ring). There is
a good visual iirc on spice-space.org .

Doing actual merging is required to move the multiple client support
from "experimental" to "production", since it is a must for different
bandwidth clients. Another long time todo.

> That could cost some host cpu though, but lower bandwidth...
> 
> There is certainly room for experimentation, improvements and tweaking!
> 
> 
> > The advantage to that crazy proposal is that it would likely make the
> > pure html5 client work 'perfectly'.  The obvious disadvantage is that
> > it
> > would consume a lot more cpu resources on the host, although it's not
> > clear to me how substantial that would be.
> 
> In general video compression is substantially more intensive than
> image compression. Long time ago, I ran some checks with vp8 (and webp)
> with speed encoding params (low quality) and it was like ~x10-x20 slower
> than jpeg-turbo iirc. Would be worth re-doing those tests, it's not
> difficult. But I was discouraged to look further at that time.
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel