----- Original Message ----- > 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? I don't think there are ready-made solution. And it's not clear what will yield best performance. Perhaps we can gather draw events calls and batch the cairo processing, either based on GdkFrameClock (if supported on macos) or some fixed interval. Since that draw event is actually just a blit/stretch/convert (not actually the desktop canvas drawing), the call can be done once in a while for the whole damaged region. A second option is to use a GL window (inside the widget). Cairo has some GL support (and some fork exist, not sure if they are all merged). So stretch/convert could hopefully be done by the GPU. I expect this solution to give some interesting results. (I wouldn't use the Spice GL canvas, but keep the current sw canvas). Also, spice-gtk needs some kind of GL context support in the widget soonish, for local 3d compositing. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel