Re: [Spice-devel] Unfair comparisons with RDP
On 06/30/2011 05:33 AM, John A. Sullivan III wrote: On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: - Original Message - Hello, all. I've been using both RDP via TSPlus and SPICE for over a week now and the practical world results at least in my mode of operation are becoming clear. SPICE does handle major screen refreshes better, e.g., monstrous graphics or continuously pasting a full line of text in a full screen notepad. Of course, SPICE is a clear winner when it comes to video though still not practically usable on low bandwidth links. However, RDP is trouncing SPICE in the more common day to day tasks involving small screen updates. For example, every time I open or switch my screen to LibreOffice, the tool bar icons seems to pain one at a time in SPICE where as they appear all at once in TSPlus. Document scrolling is more immediate and smoother. Surprisingly, when I open the PuTTY dialog in SPICE, it paints in sections whereas TSPlus appears all at once. You'll really need to post some real details here - from versions of qemu+spice server that you're using along with the qemu command line syntax, host OS, hardware details through to what's running in the guest, driver versions, etc. I've never seen RDP trounce spice, but if it does, then we need some scientific information on the environment so we can diagnose and assist. Very happy to do so as we really do want SPICE to become our protocol of choice. I believe I've posted up our details before but will do so again. Would you be so kind as to capture the Spice traffic (using tcpdump/wireshark) and send it over? Specifically: 1. Please capture from start - before the Spice client connects to the server. 2. Ensure you catch full sized packets (-s - could be 1500 most likely, when using tcpdump) 3. Save into file (-w /tmp/file.pcap when using tcpdump) 4. Please compress and send / let me know where I can pick it up from. I suggest you have only the scenario of connecting to the VM and opening putty, which you complain is slow. Hopefully it'll give us some clue. TIA, Y. The qemu side is installed entirely from Fedora 15 RPM and unpatched except for Alon's patch to fix the Windows pixel depth problem. libvirt: 0.8.8-4.fc15 qemu-kvm-0.14.0-8.fc15.x86_64.rpm qemu-common-0.14.0-8.fc15.x86_64.rpm qemu-kvm-tools-0.14.0-8.fc15.x86_64.rpm qemu-img-0.14.0-8.fc15.x86_64.rpm qemu-system-x86-0.14.0-8.fc15.x86_64.rpm The hardware is a SuperMicro AMD server with two eight core processors and 16 GB of RAM. Two bonded Gb Ethernet ports provide access to the world while two separate Gb Ethernet ports provide access to the iSCSI SAN using dm-multipath multibus. Most of the testing has been from a Debian Squeeze i386 client running on an Asus netbook to a Windows Server 2008 64 bit server. The server uses raw partitions presented via iSCSI with the following configuration: windesk02.pacad.pacifera.com 70cdeb09-f6b1-6b4d-dc2f-f72c19b9560b 4194304 4194304 2 hvm destroy restart restart /usr/bin/qemu-kvm QXL is compiled from source version 1.4.1.1. I believe vdagent (version 0.5.1.0) and vdservice (version 0.5.1.0) were compiled from source. We do have a stability problem with the agent and must regularly restart it. The Debian client was compiled from 0.8.1 source. The client test connections are a multi-Mbps Time Warner cable connection in our test lab and a Verizon 3G Mifi. The host is in a data center with relatively unlimited burstable bandwidth. If I recall the messages on stdout from the client, we are typically registering between 4 and 5 Mbps on the cable connection. Connection to the test lab is over an OpenVPN tunnel. We have checked for fragmentation and do not see any. Hmmm . . . there is a possibility the userspace encryption from OpenVPN is getting in the way but that would be a little surprising. I'll need to activate SSL connections to test that but OpenVPN would be a common usage scenario. The OpenVPN gateway is a very powerful server that is barely tapped right now. I've just taken a lengthy packet trace of graphically heavy web sites, streaming video, and switching LibreOffice screens (at which SPICE is strangely bad) and I see sustained throughput of 2.78 Mbps to 4.3 Mbps. Throughput seemed to be only around 300 Kbps when doing the LibreOffice document switches. Thus OpenVPN does not seem to be an issue; we are able to saturate the cable connection. Please let me know if you need any more information. We are
Re: [Spice-devel] [PATCH 6/6] server/red_worker: send surface images on demand (UPDATE_MEM)
On 06/20/2011 02:18 PM, Alon Levy wrote:
From: Yonit Halperin
When surfaces are being reloaded to the worker (e.g., after UPDATE_MEM), we
will send them to the client only if and when it needs them.
---
server/red_worker.c | 33 +++--
1 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index f5a2091..5a5073b 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -3404,9 +3404,9 @@ static inline void red_process_drawable(RedWorker
*worker, RedDrawable *drawable
static inline void red_create_surface(RedWorker *worker, uint32_t
surface_id,uint32_t width,
uint32_t height, int32_t stride,
uint32_t format,
- void *line_0, int data_is_valid);
+ void *line_0, int data_is_valid, int
send_client);
-static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
*surface, uint32_t group_id, int data_is_valid)
+static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
*surface, uint32_t group_id)
{
int surface_id;
RedSurface *red_surface;
@@ -3428,7 +3428,9 @@ static inline void red_process_surface(RedWorker *worker,
RedSurfaceCmd *surface
}
red_create_surface(worker, surface_id,
surface->u.surface_create.width,
height, stride, surface->u.surface_create.format,
data,
- data_is_valid);
+ surface->flags& QXL_SURF_FLAG_KEEP_DATA,
+ // reloaded surfaces will be sent on demand
+ !(surface->flags& QXL_SURF_FLAG_KEEP_DATA));
set_surface_release_info(worker, surface_id, 1,
surface->release_info, group_id);
break;
}
@@ -4290,8 +4292,7 @@ static int red_process_commands(RedWorker *worker,
uint32_t max_pipe_size, int *
red_get_surface_cmd(&worker->mem_slots, ext_cmd.group_id,
surface, ext_cmd.cmd.data);
-red_process_surface(worker, surface, ext_cmd.group_id,
-surface->flags& QXL_SURF_FLAG_KEEP_DATA);
+red_process_surface(worker, surface, ext_cmd.group_id);
break;
}
default:
@@ -8452,7 +8453,7 @@ static inline void red_create_surface_item(RedWorker
*worker, int surface_id)
static inline void red_create_surface(RedWorker *worker, uint32_t surface_id,
uint32_t width,
uint32_t height, int32_t stride,
uint32_t format,
- void *line_0, int data_is_valid)
+ void *line_0, int data_is_valid, int
send_client)
{
uint32_t i;
RedSurface *surface =&worker->surfaces[surface_id];
@@ -8485,9 +8486,11 @@ static inline void red_create_surface(RedWorker *worker,
uint32_t surface_id, ui
PANIC("drawing canvas creating failed - can`t create same type
canvas");
}
-red_create_surface_item(worker, surface_id);
-if (data_is_valid) {
-red_add_surface_image(worker, surface_id);
+if (send_client) {
+red_create_surface_item(worker, surface_id);
+if (data_is_valid) {
+red_add_surface_image(worker, surface_id);
+}
}
return;
}
@@ -8498,9 +8501,11 @@ static inline void red_create_surface(RedWorker *worker,
uint32_t surface_id, ui
surface->context.format, line_0);
if (surface->context.canvas) { //no need canvas check
worker->renderer = worker->renderers[i];
-red_create_surface_item(worker, surface_id);
-if (data_is_valid) {
-red_add_surface_image(worker, surface_id);
+if (send_client) {
+red_create_surface_item(worker, surface_id);
+if (data_is_valid) {
+red_add_surface_image(worker, surface_id);
+}
}
return;
}
@@ -9634,7 +9639,7 @@ static inline void
handle_dev_create_primary_surface(RedWorker *worker)
}
red_create_surface(worker, 0, surface.width, surface.height,
surface.stride, surface.format,
- line_0, surface.flags& QXL_SURF_FLAG_KEEP_DATA);
+ line_0, surface.flags& QXL_SURF_FLAG_KEEP_DATA, TRUE);
if (worker->display_channel) {
red_pipe_add_verb(&worker->display_channel->common.base,
SPICE_MSG_DISPLAY_MARK);
@@ -9945,7 +9950,7 @@ static void handle_dev_input(EventListener *listener,
uint32_t events)
surface_cmd = spice_new0(RedSurfaceCmd, 1);
red_get_surface_cmd(&worker->mem_slots, ext.group_id,
surface_cmd, ext.cmd.data);
-
Re: [Spice-devel] [PATCH 6/6] server/red_worker: send surface images on demand (UPDATE_MEM)
On Thu, Jun 30, 2011 at 12:36:27PM +0300, Yonit Halperin wrote:
> On 06/20/2011 02:18 PM, Alon Levy wrote:
> >From: Yonit Halperin
> >
> >When surfaces are being reloaded to the worker (e.g., after UPDATE_MEM), we
> >will send them to the client only if and when it needs them.
> >---
> > server/red_worker.c | 33 +++--
> > 1 files changed, 19 insertions(+), 14 deletions(-)
> >
> >diff --git a/server/red_worker.c b/server/red_worker.c
> >index f5a2091..5a5073b 100644
> >--- a/server/red_worker.c
> >+++ b/server/red_worker.c
> >@@ -3404,9 +3404,9 @@ static inline void red_process_drawable(RedWorker
> >*worker, RedDrawable *drawable
> >
> > static inline void red_create_surface(RedWorker *worker, uint32_t
> > surface_id,uint32_t width,
> >uint32_t height, int32_t stride,
> > uint32_t format,
> >- void *line_0, int data_is_valid);
> >+ void *line_0, int data_is_valid, int
> >send_client);
> >
> >-static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
> >*surface, uint32_t group_id, int data_is_valid)
> >+static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
> >*surface, uint32_t group_id)
> > {
> > int surface_id;
> > RedSurface *red_surface;
> >@@ -3428,7 +3428,9 @@ static inline void red_process_surface(RedWorker
> >*worker, RedSurfaceCmd *surface
> > }
> > red_create_surface(worker, surface_id,
> > surface->u.surface_create.width,
> > height, stride,
> > surface->u.surface_create.format, data,
> >- data_is_valid);
> >+ surface->flags& QXL_SURF_FLAG_KEEP_DATA,
> >+ // reloaded surfaces will be sent on demand
> >+ !(surface->flags& QXL_SURF_FLAG_KEEP_DATA));
> > set_surface_release_info(worker, surface_id, 1,
> > surface->release_info, group_id);
> > break;
> > }
> >@@ -4290,8 +4292,7 @@ static int red_process_commands(RedWorker *worker,
> >uint32_t max_pipe_size, int *
> >
> > red_get_surface_cmd(&worker->mem_slots, ext_cmd.group_id,
> > surface, ext_cmd.cmd.data);
> >-red_process_surface(worker, surface, ext_cmd.group_id,
> >-surface->flags& QXL_SURF_FLAG_KEEP_DATA);
> >+red_process_surface(worker, surface, ext_cmd.group_id);
> > break;
> > }
> > default:
> >@@ -8452,7 +8453,7 @@ static inline void red_create_surface_item(RedWorker
> >*worker, int surface_id)
> >
> > static inline void red_create_surface(RedWorker *worker, uint32_t
> > surface_id, uint32_t width,
> >uint32_t height, int32_t stride,
> > uint32_t format,
> >- void *line_0, int data_is_valid)
> >+ void *line_0, int data_is_valid, int
> >send_client)
> > {
> > uint32_t i;
> > RedSurface *surface =&worker->surfaces[surface_id];
> >@@ -8485,9 +8486,11 @@ static inline void red_create_surface(RedWorker
> >*worker, uint32_t surface_id, ui
> > PANIC("drawing canvas creating failed - can`t create same type
> > canvas");
> > }
> >
> >-red_create_surface_item(worker, surface_id);
> >-if (data_is_valid) {
> >-red_add_surface_image(worker, surface_id);
> >+if (send_client) {
> >+red_create_surface_item(worker, surface_id);
> >+if (data_is_valid) {
> >+red_add_surface_image(worker, surface_id);
> >+}
> > }
> > return;
> > }
> >@@ -8498,9 +8501,11 @@ static inline void red_create_surface(RedWorker
> >*worker, uint32_t surface_id, ui
> >
> > surface->context.format, line_0);
> > if (surface->context.canvas) { //no need canvas check
> > worker->renderer = worker->renderers[i];
> >-red_create_surface_item(worker, surface_id);
> >-if (data_is_valid) {
> >-red_add_surface_image(worker, surface_id);
> >+if (send_client) {
> >+red_create_surface_item(worker, surface_id);
> >+if (data_is_valid) {
> >+red_add_surface_image(worker, surface_id);
> >+}
> > }
> > return;
> > }
> >@@ -9634,7 +9639,7 @@ static inline void
> >handle_dev_create_primary_surface(RedWorker *worker)
> > }
> >
> > red_create_surface(worker, 0, surface.width, surface.height,
> > surface.stride, surface.format,
> >- line_0, surface.flags& QXL_SURF_FLAG_KEEP_DATA);
> >+ line_0, surface.flags& QXL_SURF_FLAG_KEEP_DATA,
> >TRUE);
> >
> > if
Re: [Spice-devel] [PATCH 6/6] server/red_worker: send surface images on demand (UPDATE_MEM)
On 06/30/2011 12:58 PM, Alon Levy wrote:
On Thu, Jun 30, 2011 at 12:36:27PM +0300, Yonit Halperin wrote:
On 06/20/2011 02:18 PM, Alon Levy wrote:
From: Yonit Halperin
When surfaces are being reloaded to the worker (e.g., after UPDATE_MEM), we
will send them to the client only if and when it needs them.
---
server/red_worker.c | 33 +++--
1 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/server/red_worker.c b/server/red_worker.c
index f5a2091..5a5073b 100644
--- a/server/red_worker.c
+++ b/server/red_worker.c
@@ -3404,9 +3404,9 @@ static inline void red_process_drawable(RedWorker
*worker, RedDrawable *drawable
static inline void red_create_surface(RedWorker *worker, uint32_t
surface_id,uint32_t width,
uint32_t height, int32_t stride,
uint32_t format,
- void *line_0, int data_is_valid);
+ void *line_0, int data_is_valid, int
send_client);
-static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
*surface, uint32_t group_id, int data_is_valid)
+static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
*surface, uint32_t group_id)
{
int surface_id;
RedSurface *red_surface;
@@ -3428,7 +3428,9 @@ static inline void red_process_surface(RedWorker *worker,
RedSurfaceCmd *surface
}
red_create_surface(worker, surface_id,
surface->u.surface_create.width,
height, stride, surface->u.surface_create.format,
data,
- data_is_valid);
+ surface->flags& QXL_SURF_FLAG_KEEP_DATA,
+ // reloaded surfaces will be sent on demand
+ !(surface->flags& QXL_SURF_FLAG_KEEP_DATA));
set_surface_release_info(worker, surface_id, 1,
surface->release_info, group_id);
break;
}
@@ -4290,8 +4292,7 @@ static int red_process_commands(RedWorker *worker,
uint32_t max_pipe_size, int *
red_get_surface_cmd(&worker->mem_slots, ext_cmd.group_id,
surface, ext_cmd.cmd.data);
-red_process_surface(worker, surface, ext_cmd.group_id,
-surface->flags& QXL_SURF_FLAG_KEEP_DATA);
+red_process_surface(worker, surface, ext_cmd.group_id);
break;
}
default:
@@ -8452,7 +8453,7 @@ static inline void red_create_surface_item(RedWorker
*worker, int surface_id)
static inline void red_create_surface(RedWorker *worker, uint32_t surface_id,
uint32_t width,
uint32_t height, int32_t stride,
uint32_t format,
- void *line_0, int data_is_valid)
+ void *line_0, int data_is_valid, int
send_client)
{
uint32_t i;
RedSurface *surface =&worker->surfaces[surface_id];
@@ -8485,9 +8486,11 @@ static inline void red_create_surface(RedWorker *worker,
uint32_t surface_id, ui
PANIC("drawing canvas creating failed - can`t create same type
canvas");
}
-red_create_surface_item(worker, surface_id);
-if (data_is_valid) {
-red_add_surface_image(worker, surface_id);
+if (send_client) {
+red_create_surface_item(worker, surface_id);
+if (data_is_valid) {
+red_add_surface_image(worker, surface_id);
+}
}
return;
}
@@ -8498,9 +8501,11 @@ static inline void red_create_surface(RedWorker *worker,
uint32_t surface_id, ui
surface->context.format, line_0);
if (surface->context.canvas) { //no need canvas check
worker->renderer = worker->renderers[i];
-red_create_surface_item(worker, surface_id);
-if (data_is_valid) {
-red_add_surface_image(worker, surface_id);
+if (send_client) {
+red_create_surface_item(worker, surface_id);
+if (data_is_valid) {
+red_add_surface_image(worker, surface_id);
+}
}
return;
}
@@ -9634,7 +9639,7 @@ static inline void
handle_dev_create_primary_surface(RedWorker *worker)
}
red_create_surface(worker, 0, surface.width, surface.height,
surface.stride, surface.format,
- line_0, surface.flags& QXL_SURF_FLAG_KEEP_DATA);
+ line_0, surface.flags& QXL_SURF_FLAG_KEEP_DATA, TRUE);
if (worker->display_channel) {
red_pipe_add_verb(&worker->display_channel->common.base,
SPICE_MSG_DISPLAY_MARK);
@@ -9945,7 +9950,7 @@ static void handle_dev_input(EventListener *listener,
uint32_t events)
surface_cmd = spice_new0(RedSurfaceCmd, 1);
red_get_s
Re: [Spice-devel] [PATCH 1/6] server/red_worker: add stream_count (for debug purposes)
Hi,
On Mon, Jun 20, 2011 at 01:18:04PM +0200, Alon Levy wrote:
> ---
> server/red_worker.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/server/red_worker.c b/server/red_worker.c
> index bee86b9..12f7fa5 100644
> --- a/server/red_worker.c
> +++ b/server/red_worker.c
> @@ -836,6 +836,7 @@ typedef struct RedWorker {
>
> uint32_t shadows_count;
> uint32_t containers_count;
> +uint32_t stream_count;
NACK from me on this patch, I'd rather remove all these unused debug
variables which are only incremented/decremented and are not used for
anything else. We already have (at least) current_size, shadows_count,
containers_count, transparent_count and drawable_count which clutter
RedWorker for no obvious gain. In this case,
ring_get_length(&worker->stream_link) might do the trick.
After having spent a few hours looking at red_worker.c, I really think we
should work on splitting it in smaller pieces, it's too huge and doing too
many things imo (it implements a main loop, message dispatching, it has
creation/destruction functions for various small objects, it has some tree
iteration code, it implements movie detection, ...). However, this would
cause bad conflicts in the pending multiclient work :(
Christophe
pgpwQxukL0iCu.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 1/6] server/red_worker: add stream_count (for debug purposes)
On Thu, Jun 30, 2011 at 12:12:59PM +0200, Christophe Fergeau wrote:
> Hi,
>
> On Mon, Jun 20, 2011 at 01:18:04PM +0200, Alon Levy wrote:
> > ---
> > server/red_worker.c |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/server/red_worker.c b/server/red_worker.c
> > index bee86b9..12f7fa5 100644
> > --- a/server/red_worker.c
> > +++ b/server/red_worker.c
> > @@ -836,6 +836,7 @@ typedef struct RedWorker {
> >
> > uint32_t shadows_count;
> > uint32_t containers_count;
> > +uint32_t stream_count;
>
> NACK from me on this patch, I'd rather remove all these unused debug
> variables which are only incremented/decremented and are not used for
> anything else. We already have (at least) current_size, shadows_count,
> containers_count, transparent_count and drawable_count which clutter
> RedWorker for no obvious gain. In this case,
> ring_get_length(&worker->stream_link) might do the trick.
>
> After having spent a few hours looking at red_worker.c, I really think we
> should work on splitting it in smaller pieces, it's too huge and doing too
> many things imo (it implements a main loop, message dispatching, it has
> creation/destruction functions for various small objects, it has some tree
> iteration code, it implements movie detection, ...). However, this would
> cause bad conflicts in the pending multiclient work :(
I think exactly the same and have no problem rebasing on top of split patches if
you want to work on that.
>
> Christophe
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 6/6] server/red_worker: send surface images on demand (UPDATE_MEM)
On Thu, Jun 30, 2011 at 01:06:43PM +0300, Yonit Halperin wrote:
> On 06/30/2011 12:58 PM, Alon Levy wrote:
> >On Thu, Jun 30, 2011 at 12:36:27PM +0300, Yonit Halperin wrote:
> >>On 06/20/2011 02:18 PM, Alon Levy wrote:
> >>>From: Yonit Halperin
> >>>
> >>>When surfaces are being reloaded to the worker (e.g., after UPDATE_MEM), we
> >>>will send them to the client only if and when it needs them.
> >>>---
> >>> server/red_worker.c | 33 +++--
> >>> 1 files changed, 19 insertions(+), 14 deletions(-)
> >>>
> >>>diff --git a/server/red_worker.c b/server/red_worker.c
> >>>index f5a2091..5a5073b 100644
> >>>--- a/server/red_worker.c
> >>>+++ b/server/red_worker.c
> >>>@@ -3404,9 +3404,9 @@ static inline void red_process_drawable(RedWorker
> >>>*worker, RedDrawable *drawable
> >>>
> >>> static inline void red_create_surface(RedWorker *worker, uint32_t
> >>> surface_id,uint32_t width,
> >>>uint32_t height, int32_t stride,
> >>> uint32_t format,
> >>>- void *line_0, int data_is_valid);
> >>>+ void *line_0, int data_is_valid,
> >>>int send_client);
> >>>
> >>>-static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
> >>>*surface, uint32_t group_id, int data_is_valid)
> >>>+static inline void red_process_surface(RedWorker *worker, RedSurfaceCmd
> >>>*surface, uint32_t group_id)
> >>> {
> >>> int surface_id;
> >>> RedSurface *red_surface;
> >>>@@ -3428,7 +3428,9 @@ static inline void red_process_surface(RedWorker
> >>>*worker, RedSurfaceCmd *surface
> >>> }
> >>> red_create_surface(worker, surface_id,
> >>> surface->u.surface_create.width,
> >>> height, stride,
> >>> surface->u.surface_create.format, data,
> >>>- data_is_valid);
> >>>+ surface->flags& QXL_SURF_FLAG_KEEP_DATA,
> >>>+ // reloaded surfaces will be sent on demand
> >>>+ !(surface->flags& QXL_SURF_FLAG_KEEP_DATA));
> >>> set_surface_release_info(worker, surface_id, 1,
> >>> surface->release_info, group_id);
> >>> break;
> >>> }
> >>>@@ -4290,8 +4292,7 @@ static int red_process_commands(RedWorker *worker,
> >>>uint32_t max_pipe_size, int *
> >>>
> >>> red_get_surface_cmd(&worker->mem_slots, ext_cmd.group_id,
> >>> surface, ext_cmd.cmd.data);
> >>>-red_process_surface(worker, surface, ext_cmd.group_id,
> >>>-surface->flags&
> >>>QXL_SURF_FLAG_KEEP_DATA);
> >>>+red_process_surface(worker, surface, ext_cmd.group_id);
> >>> break;
> >>> }
> >>> default:
> >>>@@ -8452,7 +8453,7 @@ static inline void red_create_surface_item(RedWorker
> >>>*worker, int surface_id)
> >>>
> >>> static inline void red_create_surface(RedWorker *worker, uint32_t
> >>> surface_id, uint32_t width,
> >>>uint32_t height, int32_t stride,
> >>> uint32_t format,
> >>>- void *line_0, int data_is_valid)
> >>>+ void *line_0, int data_is_valid,
> >>>int send_client)
> >>> {
> >>> uint32_t i;
> >>> RedSurface *surface =&worker->surfaces[surface_id];
> >>>@@ -8485,9 +8486,11 @@ static inline void red_create_surface(RedWorker
> >>>*worker, uint32_t surface_id, ui
> >>> PANIC("drawing canvas creating failed - can`t create same
> >>> type canvas");
> >>> }
> >>>
> >>>-red_create_surface_item(worker, surface_id);
> >>>-if (data_is_valid) {
> >>>-red_add_surface_image(worker, surface_id);
> >>>+if (send_client) {
> >>>+red_create_surface_item(worker, surface_id);
> >>>+if (data_is_valid) {
> >>>+red_add_surface_image(worker, surface_id);
> >>>+}
> >>> }
> >>> return;
> >>> }
> >>>@@ -8498,9 +8501,11 @@ static inline void red_create_surface(RedWorker
> >>>*worker, uint32_t surface_id, ui
> >>>
> >>> surface->context.format, line_0);
> >>> if (surface->context.canvas) { //no need canvas check
> >>> worker->renderer = worker->renderers[i];
> >>>-red_create_surface_item(worker, surface_id);
> >>>-if (data_is_valid) {
> >>>-red_add_surface_image(worker, surface_id);
> >>>+if (send_client) {
> >>>+red_create_surface_item(worker, surface_id);
> >>>+if (data_is_valid) {
> >>>+red_add_surface_image(worker, surface_id);
> >>>+}
> >>> }
> >>> return;
> >>> }
> >>>@@ -9634,7 +9639,7 @@ static inline void
> >>>handle_dev_create_prima
[Spice-devel] Streaming video detection
Hi I am studying the source code and how spice handles streaming video. Spice looks for area that are updated with high rate, after that it starts mjpeg_encoder. -I would like to know what are the SpiceAgent and the StreamClipItem, I see these two elements in the source code. -When spice detects video and starts to encode the video, it handles frames one by one? Spice encode one frame with mjpeg and send it to the client? Thanks. Regards. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Streaming video detection
On Thu, Jun 30, 2011 at 04:25:11PM +0200, Andrea Celestino wrote: > Hi > I am studying the source code and how spice handles streaming video. Spice > looks for area that are updated with high rate, after that it starts > mjpeg_encoder. > > -I would like to know what are the SpiceAgent and the StreamClipItem, I see > these two elements in the source code. I expect the first is to keep a handle on the stream / drawable, and the second is to update the clipping area (supposedly if you move a streamed area around, by moving a window, it should not kill and start a new mjpeg encoder but reuse it). > -When spice detects video and starts to encode the video, it handles frames > one by one? Spice encode one frame with mjpeg and send it to the client? yes. > > Thanks. > Regards. > ___ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Streaming video detection
Hi, On Thu, Jun 30, 2011 at 04:25:11PM +0200, Andrea Celestino wrote: > -I would like to know what are the SpiceAgent and the StreamClipItem, I see > these two elements in the source code. My understanding is that a StreamAgent is the object which is managing the video streaming. My guess would be that StreamClipItem describes which parts of the full screen are to be streamed as video. But I'm not really familiar with that code, hopefully someone will clear up any misunderstanding here :) Christophe pgp7Jou1Ww1tQ.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Unfair comparisons with RDP
On Thu, 2011-06-30 at 10:10 +0300, Yaniv Kaul wrote: > On 06/30/2011 05:33 AM, John A. Sullivan III wrote: > > On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: > >> > >> - Original Message - > >>> > >>> Hello, all. I've been using both RDP via TSPlus and SPICE for over a > >>> week now and the practical world results at least in my mode of > >>> operation are becoming clear. SPICE does handle major screen refreshes > >>> better, e.g., monstrous graphics or continuously pasting a full line > >>> of > >>> text in a full screen notepad. Of course, SPICE is a clear winner when > >>> it comes to video though still not practically usable on low bandwidth > >>> links. > >>> > >>> However, RDP is trouncing SPICE in the more common day to day tasks > >>> involving small screen updates. For example, every time I open or > >>> switch > >>> my screen to LibreOffice, the tool bar icons seems to pain one at a > >>> time > >>> in SPICE where as they appear all at once in TSPlus. Document > >>> scrolling > >>> is more immediate and smoother. Surprisingly, when I open the PuTTY > >>> dialog in SPICE, it paints in sections whereas TSPlus appears all at > >>> once. > >> You'll really need to post some real details here - from versions of > >> qemu+spice server that you're using along with the qemu command line > >> syntax, host OS, hardware details through to what's running in the guest, > >> driver versions, etc. > >> > >> I've never seen RDP trounce spice, but if it does, then we need some > >> scientific information on the environment so we can diagnose and assist. > >> > > > > Very happy to do so as we really do want SPICE to become our protocol of > > choice. I believe I've posted up our details before but will do so > > again. > > Would you be so kind as to capture the Spice traffic (using > tcpdump/wireshark) and send it over? > Specifically: > 1. Please capture from start - before the Spice client connects to the > server. > 2. Ensure you catch full sized packets (-s - could be 1500 most > likely, when using tcpdump) > 3. Save into file (-w /tmp/file.pcap when using tcpdump) > 4. Please compress and send / let me know where I can pick it up from. > > I suggest you have only the scenario of connecting to the VM and opening > putty, which you complain is slow. > Hopefully it'll give us some clue. > TIA, > Y. Certainly. On their way in a couple of moments. If anyone else would like a copy, please let me know off list. I took three traces. The first was our regular SPICE connection. Then I took a trace performing the same activities using xfreerdp and TSPlus. Once again, it was much more responsive and it transferred roughly 1/5th of the data SPICE did. I also noticed it said it did not support 32 bit pixel depth and reverted to 16 although it looked much better than 16. I then thought, our iSCSI disk access is slow so maybe it was a matter that all the data was now cached plus the 16 vs 32 bit pixel depth, so I took another SPICE trace with color-depth=16. It was still much slower and transferred many times the amount of data. I'll paste in the timing notes that are included in the trace tarball. One can get a anecdotal sense of how much snappier RDS is from the time lines on doing the exact same activities: SPICEStart-20110630 sequence 0 seconds: start spicec --host 172.x.x.124 --port 5900 --color-depth 32 -to previously painted screen 20: toggle to full screen 45: display desktop, i.e., minimize all open applications 64: Open PuTTY 81: Paint existing LibreOffice document, i.e., restore from minimize 104:Start new LibreOffice application after closing previous one 120:Open LibreOffice document (slowly paints toolbar icons) 136:toggle away from full screen Total bytes transfered: 2,687,446 TSPlusStart-20110630 sequence 0 seconds: start xfreerdp -d MyDomain -a 32 -x lan -z -u myid -f --plugin cliprdr --plugin rdpsnd 172.29.1.133 & - said it did not support 32 bit pixel depth and reverted to 16 although it looked much better than 16 bit 7: login 17: display desktop, i.e., minimize all open applications 28: Open PuTTY 42: Paint existing LibreOffice document, i.e., restore from minimize 58: Start new LibreOffice application after closing previous one 75: Open LibreOffice document (slowly paints toolbar icons) 85: toggle away from full scr
Re: [Spice-devel] Unfair comparisons with RDP
On Thu, Jun 30, 2011 at 02:01:48PM -0400, John A. Sullivan III wrote: > On Thu, 2011-06-30 at 10:10 +0300, Yaniv Kaul wrote: > > On 06/30/2011 05:33 AM, John A. Sullivan III wrote: > > > On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: > > >> > > >> - Original Message - > > >>> > > >>> Hello, all. I've been using both RDP via TSPlus and SPICE for over a > > >>> week now and the practical world results at least in my mode of > > >>> operation are becoming clear. SPICE does handle major screen refreshes > > >>> better, e.g., monstrous graphics or continuously pasting a full line > > >>> of > > >>> text in a full screen notepad. Of course, SPICE is a clear winner when > > >>> it comes to video though still not practically usable on low bandwidth > > >>> links. > > >>> > > >>> However, RDP is trouncing SPICE in the more common day to day tasks > > >>> involving small screen updates. For example, every time I open or > > >>> switch > > >>> my screen to LibreOffice, the tool bar icons seems to pain one at a > > >>> time > > >>> in SPICE where as they appear all at once in TSPlus. Document > > >>> scrolling > > >>> is more immediate and smoother. Surprisingly, when I open the PuTTY > > >>> dialog in SPICE, it paints in sections whereas TSPlus appears all at > > >>> once. > > >> You'll really need to post some real details here - from versions of > > >> qemu+spice server that you're using along with the qemu command line > > >> syntax, host OS, hardware details through to what's running in the > > >> guest, driver versions, etc. > > >> > > >> I've never seen RDP trounce spice, but if it does, then we need some > > >> scientific information on the environment so we can diagnose and assist. > > >> > > > > > > Very happy to do so as we really do want SPICE to become our protocol of > > > choice. I believe I've posted up our details before but will do so > > > again. > > > > Would you be so kind as to capture the Spice traffic (using > > tcpdump/wireshark) and send it over? > > Specifically: > > 1. Please capture from start - before the Spice client connects to the > > server. > > 2. Ensure you catch full sized packets (-s - could be 1500 most > > likely, when using tcpdump) > > 3. Save into file (-w /tmp/file.pcap when using tcpdump) > > 4. Please compress and send / let me know where I can pick it up from. > > > > I suggest you have only the scenario of connecting to the VM and opening > > putty, which you complain is slow. > > Hopefully it'll give us some clue. > > TIA, > > Y. > > Certainly. On their way in a couple of moments. If anyone else would > like a copy, please let me know off list. > > I took three traces. The first was our regular SPICE connection. Then > I took a trace performing the same activities using xfreerdp and TSPlus. Is the vm a windows or linux one? > Once again, it was much more responsive and it transferred roughly 1/5th > of the data SPICE did. I also noticed it said it did not support 32 bit > pixel depth and reverted to 16 although it looked much better than 16. > > I then thought, our iSCSI disk access is slow so maybe it was a matter > that all the data was now cached plus the 16 vs 32 bit pixel depth, so I > took another SPICE trace with color-depth=16. It was still much slower > and transferred many times the amount of data. I'll paste in the timing > notes that are included in the trace tarball. One can get a anecdotal > sense of how much snappier RDS is from the time lines on doing the exact > same activities: > > SPICEStart-20110630 sequence > 0 seconds:start spicec --host 172.x.x.124 --port 5900 --color-depth 32 > -to previously painted screen > 20: toggle to full screen > 45: display desktop, i.e., minimize all open applications > 64: Open PuTTY > 81: Paint existing LibreOffice document, i.e., restore from minimize > 104: Start new LibreOffice application after closing previous one > 120: Open LibreOffice document (slowly paints toolbar icons) > 136: toggle away from full screen > > Total bytes transfered: 2,687,446 > > > TSPlusStart-20110630 sequence > 0 seconds:start xfreerdp -d MyDomain -a 32 -x lan -z -u myid -f > --plugin cliprdr --plugin rdpsnd 1
Re: [Spice-devel] Unfair comparisons with RDP
On Thu, 2011-06-30 at 20:21 +0200, Alon Levy wrote: > On Thu, Jun 30, 2011 at 02:01:48PM -0400, John A. Sullivan III wrote: > > On Thu, 2011-06-30 at 10:10 +0300, Yaniv Kaul wrote: > > > On 06/30/2011 05:33 AM, John A. Sullivan III wrote: > > > > On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote: > > > >> > > > >> - Original Message - > > > >>> > > > >>> Hello, all. I've been using both RDP via TSPlus and SPICE for over a > > > >>> week now and the practical world results at least in my mode of > > > >>> operation are becoming clear. SPICE does handle major screen refreshes > > > >>> better, e.g., monstrous graphics or continuously pasting a full line > > > >>> of > > > >>> text in a full screen notepad. Of course, SPICE is a clear winner when > > > >>> it comes to video though still not practically usable on low bandwidth > > > >>> links. > > > >>> > > > >>> However, RDP is trouncing SPICE in the more common day to day tasks > > > >>> involving small screen updates. For example, every time I open or > > > >>> switch > > > >>> my screen to LibreOffice, the tool bar icons seems to pain one at a > > > >>> time > > > >>> in SPICE where as they appear all at once in TSPlus. Document > > > >>> scrolling > > > >>> is more immediate and smoother. Surprisingly, when I open the PuTTY > > > >>> dialog in SPICE, it paints in sections whereas TSPlus appears all at > > > >>> once. > > > >> You'll really need to post some real details here - from versions of > > > >> qemu+spice server that you're using along with the qemu command line > > > >> syntax, host OS, hardware details through to what's running in the > > > >> guest, driver versions, etc. > > > >> > > > >> I've never seen RDP trounce spice, but if it does, then we need some > > > >> scientific information on the environment so we can diagnose and > > > >> assist. > > > >> > > > > > > > > Very happy to do so as we really do want SPICE to become our protocol of > > > > choice. I believe I've posted up our details before but will do so > > > > again. > > > > > > Would you be so kind as to capture the Spice traffic (using > > > tcpdump/wireshark) and send it over? > > > Specifically: > > > 1. Please capture from start - before the Spice client connects to the > > > server. > > > 2. Ensure you catch full sized packets (-s - could be 1500 most > > > likely, when using tcpdump) > > > 3. Save into file (-w /tmp/file.pcap when using tcpdump) > > > 4. Please compress and send / let me know where I can pick it up from. > > > > > > I suggest you have only the scenario of connecting to the VM and opening > > > putty, which you complain is slow. > > > Hopefully it'll give us some clue. > > > TIA, > > > Y. > > > > Certainly. On their way in a couple of moments. If anyone else would > > like a copy, please let me know off list. > > > > I took three traces. The first was our regular SPICE connection. Then > > I took a trace performing the same activities using xfreerdp and TSPlus. > > Is the vm a windows or linux one? Sorry - the VM is Windows Server 2008, client is Debian Squeeze, host is Fedora 15 - John > > > Once again, it was much more responsive and it transferred roughly 1/5th > > of the data SPICE did. I also noticed it said it did not support 32 bit > > pixel depth and reverted to 16 although it looked much better than 16. > > > > I then thought, our iSCSI disk access is slow so maybe it was a matter > > that all the data was now cached plus the 16 vs 32 bit pixel depth, so I > > took another SPICE trace with color-depth=16. It was still much slower > > and transferred many times the amount of data. I'll paste in the timing > > notes that are included in the trace tarball. One can get a anecdotal > > sense of how much snappier RDS is from the time lines on doing the exact > > same activities: > > > > SPICEStart-20110630 sequence > > 0 seconds: start spicec --host 172.x.x.124 --port 5900 --color-depth 32 > > -to previously painted screen > > 20: toggle to full screen > > 45: display desk
[Spice-devel] Problem installing XP 32 bits qxl driver
Hi, I start with XP SP3 32 bits VM running on RHEL 6.0 (qemu 0.12, spice 0.6, libvirt 0.8.1). After installed virtio drivers 1.1.16 and agent with no problems. However, when select qxl video driver and try to install last version 0.6.1 xp says can not init device. Same result get with 0.6.0 driver (download from spice-space.org). Only looks working with a old driver i found in http://www.linux-kvm.com/sites/default/files/spice-windows.iso But XP then is unstable. Some seconds after boot crash and only is stable if back a vga driver. Regards, Mariano Grau mgrau @ grupojoly.com Dpto. Sistemas Grupo Joly ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
