[Spice-devel] give me some advise how to improve display effect and decrease client cpu usage

Wed Jul 3 16:00:01 PDT 2013

Hi,

On Thu, Jun 27, 2013 at 02:28:29PM -0400, Yonit Halperin wrote:
> Hi,
> On 06/18/2013 09:25 PM, bigclouds wrote:
> >
> >so much thanks Yonit:
> >1.
> >i basicly understand some of your ideas, please give me more details
> >about video pass throught, and hardware accelerate,
> >i think it is hardware related, my hardware is 1G cpu, 2 core, AMD, does
> >not has special hardware.
> >if on android platform, i am not sure if which has such hardware.
> video pass-through: with spice current implementation, videos are
> decoded inside the guest, the rendered frames reach the server, and
> then, if the server manages to classify them as video, the server
> re-encodes them (MJPEG), and the client decodes them.
> video pass-through means to stream the *original* encoded video
> (i.e., you need to catch the video in driver level, or maybe using a
> browser/player plugin), and then you decode the original video on
> the client side.

is there a preference for implementing this at the driver level (xf86-video-qxl
I assume) versus at the browser/plugin level?

thanks,

- Vasilis

> This feature might raise some licensing issues, unless decoding of
> proprietary codecs is done in the graphics driver of the client.
> By hardware acceleration, I meant encoding/decoding using the GPU.
> Maybe it will be interesting to compare gstreamer-vaapi jpeg
> decoding to libjpeg-turbo decoding. But I'm not familiar with libva,
> and how common are the graphics driver it supports. Maybe someone
> else from the team have more information about this.
> >2.
> >  improved caching , if you mean 'display tree' or send queue?   this
> >part  seems hard for me, spice use pixman directly, but there is no
> >document about pixman.  if you can ,please explain display architeture
> >to me.
> Caching: the server and client have a synchronized cache of bitmaps
> (server hold bitmaps hash keys; client holds the the actual
> bitmaps). When a bitmap is sent to the client, if it is already in
> the cache, only its id is sent, instead of the whole bitmap.
> There is --spice-cache-size option for remote-viewer. You can change
> the size of the cache and see if it improves the performance. Then
> we can consider implementing caching on disk, and not only memory.
> 
> Cheers,
> Yonit.
> >  thanks.
> >
> >
> >
> >
> >At 2013-06-19 01:44:29,"Yonit Halperin" <yhalperi at redhat.com> wrote:
> >>Hi,
> >>On 06/18/2013 10:33 AM, bigclouds wrote:
> >>
> >>>hi,all
> >>>i have used spice for a long time,it is good, but in pratice it needs
> >>>improvement, like resource usage, network bandwidth,performance.
> >>>1.it eats up much cpu on client side, up to 90% when play video. i am
> >>>sure whether decompression or something else uses so much cpu. if
> >>>client (remote-viewer) is corss-compiled to arm platform, what will
> >>>happen?  iordan has succellful compiled it to android platform.
> >>>how to decrease cpu usage on client side?(if Mplayer which Fedor  has
> >>>mention will help )
> >>For improving video streaming cpu & network usage, it would be great to
> >>have video pass-through and hardware accelerated decoding.
> >>>2.how to improve display effect and decrease network usage.
> >>>now glz algorithm seems the best, but display stuck, and mosaic (video
> >>>screen not sync) exist.
> >>By default we use auto_glz. Quic is applied on images that are
> >>classified as "real life" bitmaps. And GLZ is applied on images that are
> >>artifical (e.g., mainly contain text).
> >>>better network leads to larger traffic, some time it goes up to 7M/s.
> >>>in future spice client will be  often used  in WAN , in that case the
> >>>less trafic the better.
> >>>guys , do you have some ideas?
> >>Spice bandwidth usage is not deterministic, i.e., if you observe network
> >>usage of 7M/s on LAN, it doesn't mean that spice-server will try to push
> >>the same amount of data over WAN. Some of the bitmaps may be dropped if
> >>possible.
> >>For decreasing the bandwidth usage, you can think of features like
> >>- improved caching (e.g., try to enlarge the cache size, and if it
> >>helps, consider disk based caching).
> >>- improved lossless compression (e.g., finding identical sub-regions
> >>between bitmaps that are not necessarily "artificial" and compressed by
> >>glz today; something like a combination of a dictionary-based encoding
> >>and predictive encoding).
> >>- Instead of setting  TCP_NODELAY=0 over WAN (enabling Nagle's
> >>algorithm), concatenate small messages in the application level (i.e.,
> >>in spice server).Nagle's algorithm can lead to observed latencies due to
> >>its interaction with the delayed ack timeout on the peer side (see
> >>http://www.stuartcheshire.org/papers/NagleDelayedAck/)
> >>
> >>Regards,
> >>Yonit.
> >>>thanks
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Spice-devel mailing list
> >>>Spice-devel at lists.freedesktop.org
> >>>http://lists.freedesktop.org/mailman/listinfo/spice-devel
> >>>
> >>
> >
> >
> >
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel