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.
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Reply via email to