> Frediano Ziglio писал 2020-05-25 10:19: > >> > >> I have a problem with slow rendering of a changing desktop via a slow > >> network. SPICE tries to render all the states of the screen > >> sequentially, instead of immediately drawing the final state. > >> > >> What settings can you remove this behavior? > > > > Hi, > > I'm not sure, unfortunately, there's a way to entirely remove this > > behavior, > > at least with current optimizations. > > Can you describe better your case? > > What's slow mean, I mean, speed? 10Mbit? Less? More? > > Do you know the latency of the connection? > > What type (mobile/wifi/cabled/lan/wan) ? > > Which kind of guest (OS/configuration/use case) are you using? > > In the subject you state a "slow network" in the message you speak > > about "slow rendering", that's quite different from the way I see it, > > what specific issues are you noting? > > > > Frediano > > The channel is UDP OpenVPN via the Internet. The total load from > everything turns out to be about 100Kib. But this is not a direct > channel limitation. The channel may be larger. If you use the TCP > version of OpenVPN, then it will be displayed even more slowly. It seems > that the server is waiting for some confirmation from the client. > > Client and server Ubuntu 18.04. > > With a smooth fading or brightening of the Windows screen on a virtual > machine on the client, I see all the successively changing brightness. > The same thing happens when a video or something changes is drawn in the > browser. > > Hi, not much to recommend with these conditions. I think quite out of SPICE can handle. The original design was more about sending rendering commands to clients which does not help much with so slow bandwidth. One of the 2 options to try is to force "wan optimization" setting it to "always". This will use more JPEG for compression. Another would be to reduce "jpeg_quality" setting (dcc.cpp) to a lower value (currently fixed to 85). An unfortunately VPN and queueing does not help, especially if TCP. The reason is that while the server (which mainly send data) has a fast connection to the VPN gateway the client doesn't so the server probably will use a large queue causing latency issues. I have a quite dirty and experimental patch to limit the queue but it won't help with other issues. I think (it could be I'm wrong) that an approach more VNC like (drawing all at host/guest level then send the collapsed changes to client) would be better. I have another dirty patch but at the moment is even worse at the optimization level so won't help too. Regards, Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel