From: Marc-André Lureau
Thos function shows up in some profiling results, it seems we can
trivially replace it with a precomputed array of 256bytes.
---
common/canvas_base.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/common/canvas_base.c b/co
This is actually for spice-common (although spice-gtk will need later then)
On Tue, Sep 10, 2013 at 11:13 PM, Marc-André Lureau
wrote:
> Make it explicit that 100 is the last value of the base channel
> messages. This allows clients to use the generated enum value too.
> ---
> spice.proto | 2 ++
Make it explicit that 100 is the last value of the base channel
messages. This allows clients to use the generated enum value too.
---
spice.proto | 2 ++
1 file changed, 2 insertions(+)
diff --git a/spice.proto b/spice.proto
index 8aa35c1..acd5155 100644
--- a/spice.proto
+++ b/spice.proto
@@ -1
argh, I reintroduced it by mistake..
On Tue, Sep 10, 2013 at 9:15 PM, Yonit Halperin wrote:
> Hi,
>
>
> On 09/10/2013 10:44 AM, Marc-André Lureau wrote:
>>
>> From: Marc-André Lureau
>>
>> The current coroutine channel_iterate() creates a GSource for the socket
>> reenters the mainloop waiting f
Hi,
On 09/10/2013 10:44 AM, Marc-André Lureau wrote:
From: Marc-André Lureau
The current coroutine channel_iterate() creates a GSource for the socket
reenters the mainloop waiting for IO condition. This is really heavy
usage of mainloop showing up in system time and user space
profiling (10% o
From: Marc-André Lureau
We can avoid repetitive computation by using two precomputed array, of
4k each.
---
common/quic.c | 25 -
common/quic_family_tmpl.c | 22 +-
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/common/qui
---
spice.proto | 2 ++
1 file changed, 2 insertions(+)
diff --git a/spice.proto b/spice.proto
index 5eede6b..8aa35c1 100644
--- a/spice.proto
+++ b/spice.proto
@@ -425,6 +425,8 @@ flags8 string_flags {
};
flags32 surface_flags {
+/* Adding flags requires some caps check, since old client
On 09/10/2013 10:44 AM, Marc-André Lureau wrote:
Allow to disable selectively channels, mainly used for testing,
ex: SPICE_DISABLE_CHANNELS=display spicy-stats -p 12345
---
gtk/spice-channel-priv.h | 2 ++
gtk/spice-channel.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/gt
On 10/09/13 01:16, Alon Levy wrote:
>> Hi
>>
>> - Original Message -
>>> Hi,
>>>
>>> I've played around a bit with xpra[1]. Xpra (AFAIK) starts an X server with
>>> a
>>> dummy video driver (or xvfb?) on the remote machine and a client xpra
>>> process
>>> on the local machine shows remote
hi:
Thanks for your hard work,and sorry for my English is poor.
I use aSPICE download from http://spice-space.org/download.html in my
android device,but it doesn't support usbredir.
so,if I want to do so,how can do it? Are you planning a version with usbredir?
Quoting Alon Levy (al...@redhat.com):
> > Quoting Alon Levy (al...@redhat.com):
> > > > Hi,
> > > >
> > > > it has been reported
> > > > (https://bugs.launchpad.net/ubuntu/+source/spice/+bug/1212704)
> > > > that in a multi-monitor setup with partial overlap, spicy runs fine but
> > > > spicec ref
From: Marc-André Lureau
This simplifies a little bit function calling, and allows for compiler
to potentially specialize and optimize a bit better each version.
---
common/quic_family_tmpl.c | 4 ++--
common/quic_rgb_tmpl.c| 6 +++---
common/quic_tmpl.c| 16
3 file
> Quoting Alon Levy (al...@redhat.com):
> > > Hi,
> > >
> > > it has been reported
> > > (https://bugs.launchpad.net/ubuntu/+source/spice/+bug/1212704)
> > > that in a multi-monitor setup with partial overlap, spicy runs fine but
> > > spicec refused to run. This is explicitly checked for in
> >
From: Marc-André Lureau
---
gtk/channel-display.c | 4 ++--
gtk/spice-channel.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index 45d31c5..0af3859 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@ -6
Quoting Alon Levy (al...@redhat.com):
> > Hi,
> >
> > it has been reported
> > (https://bugs.launchpad.net/ubuntu/+source/spice/+bug/1212704)
> > that in a multi-monitor setup with partial overlap, spicy runs fine but
> > spicec refused to run. This is explicitly checked for in
> > client/x11/pla
> Hi,
>
> it has been reported
> (https://bugs.launchpad.net/ubuntu/+source/spice/+bug/1212704)
> that in a multi-monitor setup with partial overlap, spicy runs fine but
> spicec refused to run. This is explicitly checked for in
> client/x11/platform.cpp:crtc_overlap_test().
>
> I've looked at t
> On 10/09/13 01:16, Alon Levy wrote:
> >> Hi
> >>
> >> - Original Message -
> >>> Hi,
> >>>
> >>> I've played around a bit with xpra[1]. Xpra (AFAIK) starts an X server
> >>> with
> >>> a
> >>> dummy video driver (or xvfb?) on the remote machine and a client xpra
> >>> process
> >>> on the
Hi,
it has been reported
(https://bugs.launchpad.net/ubuntu/+source/spice/+bug/1212704)
that in a multi-monitor setup with partial overlap, spicy runs fine but
spicec refused to run. This is explicitly checked for in
client/x11/platform.cpp:crtc_overlap_test().
I've looked at the git tree for th
From: Marc-André Lureau
The cache code isn't very quick, it shows up in profilers. Using
GHashTable allows to simplify the code while making it faster.
---
gtk/channel-cursor.c | 56 +++
gtk/channel-display.c | 93 +++---
gtk/spice-
On Mon, Sep 9, 2013 at 9:26 PM, Yonit Halperin wrote:
> ack, but what happens when g_slice_new fails? the spice_new and other spice
> malloc functions handle mallocs that fail and abort in such cases.
glib functions abort on allocation failure by default.
>
>
> On 09/08/2013 02:59 PM, Marc-André
From: Marc-André Lureau
That doesn't seem to really improve performance so much,
but that' s what we should do probably.
---
gtk/spice-util.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/gtk/spice-util.c b/gtk/spice-util.c
index e02fc4d..4372f28 100644
--- a
From: Marc-André Lureau
Use of coroutines allow to simplify spice_channel_recv_msg(), it doesn't
need to keep current reading state, it can rely on the coroutine stack
for that.
---
gtk/channel-base.c | 1 +
gtk/spice-channel-priv.h | 3 +--
gtk/spice-channel.c | 50 +++-
As pointed out by Yonit on the ML:
> (1) the palette cache shouldn't be shared among the display channels. I.e.,
> there should be one instance per channel, and not one instance in
> spice-session.
---
gtk/channel-display.c| 4 +++-
gtk/spice-session-priv.h | 1 -
gtk/spice-session.c | 6
---
gtk/channel-base.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-base.c b/gtk/channel-base.c
index abcf9d9..646042d 100644
--- a/gtk/channel-base.c
+++ b/gtk/channel-base.c
@@ -169,12 +169,12 @@ void spice_channel_handle_migrate(SpiceChannel *channel,
On Mon, Sep 9, 2013 at 10:22 PM, Yonit Halperin wrote:
> ack.
>
> Notice that basically handle_msg of all the channels does the same, expect
> it uses different msg handlers. It would have been cleaner to use one
> handle_msg routine, and different msg handlers. Then, instead of checking
> disable
From: Marc-André Lureau
The current coroutine channel_iterate() creates a GSource for the socket
reenters the mainloop waiting for IO condition. This is really heavy
usage of mainloop showing up in system time and user space
profiling (10% of CPU time spent in mainloop overhead). Instead flush
al
With a Spice replay (a tool not yet merged, but available in dev
branches), the following commit improves a little bit performance by not
spending so much CPU time in looking up surfaces. I found initially
hotspot with "perf", and get a consistant ~200ms speedup with "time
spicy-stats" after replac
On Mon, Sep 9, 2013 at 11:11 PM, Yonit Halperin wrote:
> Looks good. see comment bellow.
>
> On 09/08/2013 02:59 PM, Marc-André Lureau wrote:
>>
>> From: Marc-André Lureau
>>
>> Use of coroutines allow to simplify spice_channel_recv_msg(), it doesn't
>> need to keep current reading state, it can
Checking by value make the flag fields useless. Unfortunately, when
adding more flags, the server will have to ensure it can safely send it,
by checking some of new client caps (for some features).
---
gtk/channel-display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gtk/
Avoid hard-coding surface 0 as being primary, although in practice it
always is so far. Also a lot of lookups are primary, so add a shortcut
for this special case (~30% apparently), it shows some small lookup
speedup.
before:
real 0m5.008s
user 0m3.253s
sys 0m2.015s
after:
real0m
On Mon, Sep 9, 2013 at 9:19 PM, Yonit Halperin wrote:
> Hi,
>
> In general it looks good, but I have several comments:
>
> (1) the palette cache shouldn't be shared among the display channels. I.e.,
> there should be one instance per channel, and not one instance in
> spice-session.
Ok, I thought
This allows to simplify a little bit derived class, to avoid overriding
handle_msg, and allows the base class more flexibility (for example for
filtering messages, as in the following patch)
---
gtk/channel-base.c | 39 +++
gtk/channel-cursor.c | 43 -
Improve a bit the code by using hashtable ownership.
---
gtk/channel-display.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index a0bdec1..8734721 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@
Allow to disable selectively channels, mainly used for testing,
ex: SPICE_DISABLE_CHANNELS=display spicy-stats -p 12345
---
gtk/spice-channel-priv.h | 2 ++
gtk/spice-channel.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/gtk/spice-channel-priv.h b/gtk/spice-channel-priv.h
inde
This allows to simplify a little bit derived class, to avoid overriding
handle_msg, and allows the base class more flexibility (for example for
filtering messages, as in the following patch)
---
gtk/channel-base.c | 39 +++
gtk/channel-cursor.c | 43 -
---
spice-common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/spice-common b/spice-common
index fc27fb2..a58791a 16
--- a/spice-common
+++ b/spice-common
@@ -1 +1 @@
-Subproject commit fc27fb20b8ecd3e07809aec884f99f2121712bc9
+Subproject commit a58791a9deab841c123f5c4efa
> > Who handles the keyval, do you have corresponding qemu or agent patch?
> > Or are you using this only with XSpice somehow? It would be nice if we
> > could get the full picture before amending this.
>
> I am writing a spice based terminal server. But I need a few more days until
> that code is
> Who handles the keyval, do you have corresponding qemu or agent patch?
> Or are you using this only with XSpice somehow? It would be nice if we could
> get the full picture before amending this.
I am writing a spice based terminal server. But I need a few more days until
that code is ready for r
Hi,
Who handles the keyval, do you have corresponding qemu or agent patch?
Or are you using this only with XSpice somehow? It would be nice if we
could get the full picture before amending this.
thanks
On Tue, Sep 10, 2013 at 6:55 AM, Dietmar Maurer wrote:
>
> Signed-off-by: Dietmar Maurer
> -
Fernando Lozano píše v St 28. 08. 2013 v 12:36 -0300:
> Hi Uri,
> >> I am also worried about authentication using spice+tls. Any user, from
> >> any machine, can connect to the spice+tl port. But using an ssh tunnel
> >> means each user needs his own ssh password or key.
> >
> > One can use passwor
40 matches
Mail list logo
