[Spice-devel] 答复: how to let spice-server send all the rendering work to the client side

[Marc-André Lureau]

Hi

----- Original Message -----
> Then, I got another question. If all the commands are sent to client
> gennerally as long as the network is not so bad,  does spice need to
> evaluate
> client resource in advance, or it just checks network congestion situation？

Take what I say with some distance, as I didn't write and participate much to
the server & driver code.


> For now, I know that file spice/server/red_worker.c and
> spice/server/red_dispatcher.c does the job getting the qxl commands, putting
> commands
> into a ring, a tree, a queue, packing them into spice message and sending
> them to spice client, but which part of code is responsible for the
> corresponding
> functions? There are so much lines in these source code files, and I am not
> good enough to master this at once, but I want to. Could you show me some
> source code with their specification related with the "dynamically adjust"
> module?


There is an inital measurement when sending data in burst, to adjust default settings.

Then the adjustment is done via the current size of the pipe and in case of video
playback, there is some dynamic adjustment via qos reports.

I think the current code blocks rendering if the pipe is full (so guest should start dropping frames itself).

Now you can see some analysis of the rendering tree in red_current_add(), in some cases rendering commands are dropped.

When there are too many drawables hold by the server (so it's not the client pipe or the memory), the server starts to free drawables. In free_one_drawable() there is a call to red_draw_drawable().. I had the idea that this would also drop client pipe item and effectively reduce the number of commands, but I can't find any evidence of that now.

There are a lot of interesting ideas in the server code. But by lack of documentation and a quite unpleasant code (to stay polite), it's really hard to figure it out.

> 
> What's unique and birlliant in spice, I think, is its ablility to transmit
> and handle 2D graphic commands, not like other remote desktop solutions
> using frame buffer updates. This is a great leap, I want to comprehend it,
> how it fulfill its duty, how it complete its job.

Sadly, all of this is now irrelevant for modern desktops using 3d apis.