[Spice-devel] UPDATE: spice-gtk on MAC OSX

[Mario]

Am 23.10.2013 15:03, schrieb Marc-André Lureau:
> Hi
> 
> On Tue, Oct 22, 2013 at 4:33 PM, Mario <ml at kernelobjects.org> 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 at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>> 
>>> _______________________________________________
>>> Spice-devel mailing list
>>> Spice-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>> 
>> _______________________________________________
>> Spice-devel mailing list
>> Spice-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/spice-devel