It would be nice to be able to create a cairo surface on quartz that is backed by a CGContext from a CGLayer to get better performance (CGBitmapContext seems to be very slow, most likely done completely in software, while CGLayers are closer to pixmaps on X11). This will require 10.4 though. GTK+ could then use CGLayer to represent GdkPixmap instead of a bitmap context.
I have a patch for that sitting around here somewhere, but it wasn't really any faster on my benchmarks; I never finished it completely though, and there were a few oddities in the API. Nothing stops the app (gtk in this case) from creating a CGLayer and just creating a cairo surface that renders to it...
OK, sorry to hear you didn't see any performance improvements. I was hoping it could at some point be used instead of a bitmap in create_similar etc. Do you have that patch somewhere if I want to play around with it? About creating a surface from a CGLayer, I did try that. I first tried creating a layer, then a cairo surface for its cgcontext, drew to the cairo surface, and then used the surface as source to paint to the "screen's" surface. But this made the surface end up in error state for some reason so I figure it needs some adjustments to be supported.
I'll try to dig up the patch and attach it here. But I would focus on the second thing that you tried. I'm guessing that the issue was that you tried to use cairo to paint from the CGLayer surface to the screen (also CG) surface; code is probably missing to handle CGLayer-backed surfaces in that operation. That shouldn't be hard to fix, but I would use CG directly at that point (since you have the Layer and you have the destination CG context).
Ah, I can try using CG directly off course, at least to see if I get any performance improvements, thanks for the idea.
OK, that worked nicely for my test. Unfortunately you are right, no noticable improvement, which is weird as all the docs talk about CGLayer as being much more efficient, and being stored in video memory etc etc. Maybe it depends on the hardware. Also I am applying transforms and clipping which seem to slow down quartz a lot anyway.
I did some testing to figure out why the cglayer approach was as slow as the bitmap way, and it seems like as soon as you flip the coords, drawing a cglayer to a cgcontext gets really slow :/
I have a patch for this in http://hg.mozilla.org/mozilla-central/file/tip/gfx/cairo. CGLayers aren't super-fast as claimed in Apple docs, but they're better than CGBitmapContexts for some things, like self-copies, and they're not slower if you're careful about flipping coordinates. See http://weblogs.mozillazine.org/roc/archives/2010/05/cglayer_perform.html
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/1.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.