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.
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.
thanks.
At 2013-06-19 01:44:29,"Yonit Halperin" <yhalperi@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/spice-devel >> >
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel