Am 23.10.2013 15:03, schrieb Marc-André Lureau:
Hi
On Tue, Oct 22, 2013 at 4:33 PM, Mario <ml@xxxxxxxxxxxxxxxxx> wrote:
Hi,
[...]
It would be nice if you could share your sdl wip patch, perhaps that
could help spot the issue.
Sure - but - to be honest with you - this implementation is a kludge. It
just rederes to a second SDL-window instead of rendering into the gtk
windget. Inputs are still received from the widget. No error catching
and no gtk adjustment at all. If the rendering would be faster I would
investigate to integrate it (especuially as SDL is available for Windows
and Linux as well) and provide a releasable patch but presently this
seems more to be a dead end.
But for testing it is enought to see that even Open GL rendering is not
that fast (like seen on windows/linux). Maybe the Quartz part was in
fact not our (only) issue.
Additional I removed a lot of optional code of the gtk client so a patch
would not show up the relevant parts. Sorry but I have almost no
experience with glib. My focus is on C (user space as well as kernel
space) but that emission of "string" signals and coroutine
implementation is new to me :(
I guess there are two different solutions to keep you involved: Either I
could send you a tar of my source folder or I could arrange a login on
my OSX build machine for you including VNC access to see what happens on
the screen (that is my preference except you have an own OSX machine).
If you could send me your ssh pubkey I would arrange the access.
Do you know what gl texture format is being used? Have you searched
for the reasons why gltexsubimage can be slow? I found for example
http://www.clearchain.com/blog/posts/opengl-gltexsubimage2d-very-slow-a-solution.
Not yet. As the performance monitoring show me that there was an
acceleration compared to quartz (in relative processing time) I guess
there is still a different part that brakes the performance. Because
even with that acceleration the look and feel was absolutely identical
to the quartz rendering into the widget.
Have you thought about further aggregating the draw events at a fixed
interval, as I proposed earlier?
I looked into the code and have some questions about it.
So I guess you mean that the drawing functions in channel-display.c
sould execute the DRAW() but they sould not emit the invalidate,
correct?
So my idea would be to save the changed rectange in the private part of
the display channel. Every call to a DRAW() would be able to extend that
rectangle to be sure that the whole part of the surface is drawn to the
screen on the update - does this make sense to you?
So how may I use the emission of the invalidation signal? Am I allowed
to emit that signal by an own thread?
Further I checkt the performance with different setups:
- A Linux Console (no X) as guest is very, very slow in the mac client.
- An Ubuntu guest is quite better than the Windows guest. Even moving
windows and resizing them is fairly smooth on the gtk client running on
OSX.
- A video in a Windows guest is shown smoothly in the OSX gtk client.
Only resizing and moving a window is deadly slow.
Do you have any idea why there is such a difference?
Thank you so much.
Cheers,
Mario
thanks for your effort so far
Thanks in advance,
Mario
Am 16.10.2013 10:37, schrieb Mario:
Hi,
I just took a look into those functions that are not seem to be
involved in performance issues. Until today I stopped at the
gdk_window_update_idle() as this call is suggestive of being
innocent.
I thought it may sleep.
However this calling thread seem to create the performance issue on
OSX.
Attached you´ll find the time analysis of the spicy client (as png as
text exports of this software are not really clear).
Deep inside the gdk_window_update_idle() the drawing function
spicex_draw_event() is called that actually consumes 65% of the whole
execution time.
Inside cairo_fill() the CGContextDrawImage() is called for the quartz
backend and this seem to be the root of all evil. ;-)
Is there any other approach to display the spice-widget content to
the
screen?
Thanks in advance,
Mario
Am 07.10.2013 11:55, schrieb Mario Lombardo:
Hi,
I just compiled the spice-gtk client (spicy) on OSX
(http://www.spice-space.org/page/OSX_Client/Build).
I am able to connect to the spice server using this client but it is
more slow than any VNC client I know.
I looked into the code and found two different places where this
client seems to be different than the x11 or GDI versions:
1.) It uses sw_canvas.c
2.) It uses spice-widget-cairo.c
Is it possible that the slow rendering results in the execution time
one of those two files? Which investigation would make more sense:
Would it be better to provide a SDL cairo version or should it
accelerate the client when there is a canvas option optimized for OSX
(quarz I guess)? Is it possible to test the gl canvas on OSX? I
didn´t
found anything about the gl implementation in the configure script.
Thank you.
Mario
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel