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

[Yonit Halperin]

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.
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
>>>
>>
>
>
>