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

[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.

> 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.

> 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.

> related to the patch of Yonit Halperin (cropping of bitmaps / also
> Windows 7 related)?
> 
> 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 at kernelobjects.org> 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 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
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>