Hi Marc,
Am 26.10.2013 16:53, schrieb Marc-André Lureau:
Hi
----- Original Message -----
Marc,
as I wrote im my last mail my SDL drawing backend was not as
successful
as expected. However I started to create a complete SDL client. This
client uses the spice-glib but has no relation to gtk or spice-gtk at
all.
Attached you´ll find my WIP code. In fact it is quite basic. No
keyboard
events at present. No sound. No server side mouse rendering - no mouse
pointer change. (not yet)
I just implemented the SDL drawing and the mouse events to reproduce
the
performance issue I noticed with the gtk client.
So as it seems it is a bit faster as the gtk widget. But it is still
quite slow compared to its windows and linux friends.
So everything points to a performance issue on OSX using the
spice-glib.
I don't have the same conclusion based on your earlier profiling
results.
Sorry for the confusion - I´m not saying that the gtk implementation on
OSX (using Quartz) is innocent. But even without any gtk there is still
the behaviour of the spice client absolutely different to other client
architectures like spice-gtk on Windows or spice-gtk on Linux.
This issue is present especially when I move windows (on Windows) or
maximize the internet explorer (on Windows).
That is, when updating very large drawing regions.
Theoretical d'accord. But when I move a window on a Linux guest the
performance is quite better (even using the spice-gk on OSX).
What does Windows different to other OSes? Is it possible that this is
Windows cairo uses Stretch/BitBlt operations, from there it really
depends on capabilities and implementation of drivers. But in general,
there is no opengl texture conversion, hopefully.
Sorry again for confusion. I´m talking about the guest OS. Different
OSes as guest within a KVM/qemu environment are resulting in different
behaviour for my spice-gtk on OSX.
Is cairo and its functionset a part of the spice-glib? I thought it is
just the implementation of the drawing part within spice-gtk and not of
the spice-glib itself. As my WIP client does not make any use of the
spice-gtk library there is no use of the cairo funtions as well.
As much as I unserstood the code the drawing into the image in the
memory is done by pixman only. So my code uses pixman (via spice-glib)
for rendering operations and SDL for presenting the image. Is this
correct?
Did you try the SDL code of my last mail? You just need pkgconfig,
spice, spice-glib-2.0 and SDL2. You may want to change the
create-primary callback as describted in my code comment (this was a
test in past where the spice-glib direct should create a SDL surface
instead of just malloc it).
related to the patch of Yonit Halperin (cropping of bitmaps / also
Windows 7 related)?
Did you take a look into the patch I mean? This also affects Windows 7
Thank you for your support!
Cheers
Mario
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,
>>
>> bad news related to the OSX Client.
>>
>> I just finished implementing a SDL "alpha-" backend for the gtk
>> widget. as I
>> did not figure out how to draw into an existing window I was opening a
>> new
>> windows using SDL and implemented a draw-function for my
>> spice-widget-sdl.c
>> that simply takes the pixman data and draws it into the SDL window.
>> SDL uses
>> opengl to for accelerated 2d drawing on my OSX machine.
>>
>> Measuring the performance I figuread out that the SDL was in fact
>> faster
>> than the quartz backend of cairo. However the look and feel did not
>> change
>> at all :(
>>
>> Even with accelerated rendering there is almost no difference between
>> cairo/quartz and sdl/opengl drawing. I was woundering if you had any
>> idea
>> how I can proceed. I don´t know the spice client that good to know
>> exactly
>> where to look next.
>>
>>
>> Here you find the opengl variant of my SDL drawing graph:
>> http://wwwlehre.dhbw-stuttgart.de/~lombardo/spicex_draw_event_opengl.png
>>
>> Here was the call tree with execution time for the quartz backend:
>> http://wwwlehre.dhbw-stuttgart.de/~lombardo/exp_call_tree_spicy.png
>>
>> So I came from 65,9% of processing time to 42,1% for the
>> spicex_draw_event()
>> function. But there is absolutely no effect visible for the user.
>>
>> Any hint would be great!
>
>
> It would be nice if you could share your sdl wip patch, perhaps that
> could help spot the issue.
>
> 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.
>
> Have you thought about further aggregating the draw events at a fixed
> interval, as I proposed earlier?
>
> 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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
