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