[Spice-devel] xf86-video-qxl performance

[Yonit Halperin]

On 05/24/2012 05:30 PM, Jeremy White wrote:
>> No, what we do is combine some operations (change/drop) by looking at
>> current outstanding messages (queued but not yet sent - in the pipe)
>> whenever we read a new message from the device (from the ring). There is
>> a good visual iirc on spice-space.org .
>
> I didn't find a visual that address that specifically; although
> the spice for newbies does have a lot of information which I haven't
> fully digested yet.
>
> I do think I have the beginning of a thread to understand the specific
> bug I'm seeing.  I see on the client that I get 500 or so draw fill
> operations each time I move the mouse over a menu choice.  If we require
> an ack every 20, at a WAN price of 80 ms per ack, you very rapidly go
> right down the tubes.  So figuring out why those draw fill operations
> didn't get condensed seems like the right place to start.
>
Hi,
Just to clarify, we currently don't condense messages in spice-server, 
though it is another item in our TODO.
In order to verify your suggestion, you can disable acks for the display 
channel (s/handle_acks=TRUE/handle_acks=FALSE in the call to 
red_channel_create in red_worker.c). You can also modify the values of 
NARROW/WIDE_CLIENT_ACK_WINDOW in red_worker.c, and also change 
red_channel_client_waiting_for_ack to multiply the client window with a 
bigger factor than 2.

Regards,
Yonit.
> Am I on the right track in looking at red_current_add in red_worker.c?
> And it looks like turning on PIPE_DEBUG may well get me a whole lot more
> info - I'll start with that.  Any other tips or clues are appreciated.
>
> Cheers,
>
> Jeremy
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel