> Now, if that's _still_ too slow, then the next thing to address is > perhaps in the X server itself, (ideally, it would be able to use the > video hardware for the rotation, and not require much CPU at all). So, > it's a question of how good the support is for rotated images in your > server's implementation of the Render extension. Switching to use an Xlib surface didn't really help.  So you're saying that it's a problem with my X server setup?  Cairo itself should be using the Render extension already?  Sorry for the simple questions, I'm still new to cairo. > Are you using a cairo snapshot between 1.3.2 and 1.3.12? Yep, that was the problem.  Thanks a lot for the help. <div>On 2/20/07, Carl Worth <<a href="mailto:cworth@cworth.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">cworth@cworth.org </a>> wrote:<blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex"> On Tue, 20 Feb 2007 16:03:05 -0600, "Glenn Murphy" wrote: > When I added the rotation is when I first hit this problem. I was rendering > everything on each refresh, so the application was sucking up a lot of CPU > time. I changed it to draw everything to a ImageSurface the one time and > then paint that to the screen when the expose-event was signaled. Whenever > the expose-event signal is received, all it does is create a cairo context > (using gtk.gdk.Window.cairo_create()), translate to the center, rotate 1 > degree and paints the ImageSurface. However, after doing all that, it still > sucks up a lot of CPU time from redrawing the DrawingArea all the time. > expose-event is getting signaled a lot (about 30 times a second) and each > time it has to redraw the entire DrawingArea. If you're painting an image surface every time, then you will be transferring all of the image data from your application to the X server every time. So, better would be to have your intermediate surface as an xlib surface, (or whatever surface type your destination is). You can create one of those with cairo_surface_create_similar. Given a cairo_t* cr from gdk_cairo_create that would be something like: surface = cairo_surface_create_similar (cairo_get_target (cr),                                         CAIRO_CONTENT_COLOR[_ALPHA],                                          width, height); Hopefully it's obvious to you how to translate that from C to python. Now, if that's _still_ too slow, then the next thing to address is perhaps in the X server itself, (ideally, it would be able to use the video hardware for the rotation, and not require much CPU at all). So, it's a question of how good the support is for rotated images in your server's implementation of the Render extension. > Another problem I've been having is from rotating the ImageSurface. Whenever > I rotate it, the image created is moved outside of the clipping region. > Every 90 degrees, it moves back to the correct position. I haven't been able > to find anything about this problem. I have three images showing this > problem: Are you using a cairo snapshot between 1.3.2 and 1.3.12? That looks an awful lot like a bug that was fixed in the 1.3.14 snapshot which was described as follows in the release notes:         Fix corrupted results when rendering a transformed source image         surface to an xlib surface. This was a regression that had been         present since the 1.3.2 snapshot.         [<a href="http://cairographics.org/news/cairo-1.3.14" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://cairographics.org/news/cairo-1.3.14</a>] I hope that helps. And have fun with cairo, -Carl </blockquote></div>