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

[Zhicheng Li(Emmannel)]

Yeah, lack of documentation and lack of hardware level development experience is now the biggest problem for me.
The five documents on spice-space website have been read over and over again by me, trying to figure out something that will help understand the source code. Sadly, I just got something that can be taken "from some distance", and few things related to source code have been found. Mailing list is a fantastic place, but sometimes the level is too high, or too abstract, and some code patches are too hard to get in. As far as the source code itself, to be honest, it may be brilliant, but it's so brilliant that it just take a genius to understand it without appropriate comment annotation(lol).

Now is nearly midnight in east China, I'm going for my bed. May you guys continue a good day.
________________________________________
发件人: Marc-André Lureau [mlureau at redhat.com]
发送时间: 2014年5月6日 20:01
收件人: Zhicheng Li(Emmannel)
Cc: spice-devel at lists.freedesktop.org
主题: Re: [Spice-devel] 答复:  how to let spice-server send all the rendering work to the client side

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.