[cairo] [PATCH 1/2] gl: Add a first bit of general documentation on cairo-gl usage.

[Eric Anholt]

On Tue, 01 Feb 2011 16:58:04 +0100, Benjamin Otte <otte at redhat.com> wrote:
> On Mon, 2011-01-31 at 23:57 -0800, Eric Anholt wrote:
> > + * Cairo-gl does not unbind its context after its rendering, and
> > + * OpenGL requires that a context being bound to a thread not
> > + * currently be bound to a different thread .  Therefore, an
> > + * application using cairo-gl surfaces from multiple threads must
> > + * manually unbind the cairo_device_t's context from the leaving
> > + * thread before calling cairo from the entering thread.
> >  
> I don't think that change is gonna work if you want to allow anything
> multithreaded in cairo-gl. Neither Wayland-GTK nor GStreamer will be
> able to work with cairo-gl this way.
> 
> The reason is that cairo-gl does not just acquire the context upon
> drawing with stroke/fill/mask/show_glyphs, but also when it's used as a
> source or even with cairo_surface_write_to_png(). Which de-facto means
> that in your app, if you grab a surface from GTK, you must call
> glXMakeCurrent(NULL) if you intend your lib to work in a multithreaded
> application.
> 
> But it's interesting that we actually do have performance differences
> these days with avoiding glXMakeCurrent(NULL), because when I added it,
> I benchmarked it and there was virtually no difference at all. So I
> guess that's new code that Mesa grew in recent times?

I saw the massive performance hit from the moment you introduced the
context unbinding -- I'm not sure what you'd have been benchmarking that
didn't.  Perhaps one of the few tests that's GPU limited?  I've got some
hacks to Mesa to slightly reduce the pain of unbind (which the
benchmarking I reported was actually done against), but I really don't
see anything to reduce it further than the couple of percent I've got
right now.  One of the rules of making GL work reasonably is to not
glFlush(), and the threading model you propose requires glFlush() on
every exit of cairo.  As far as I can see, if we're going to require
that, then we should abandon cairo-gl because it's not actually a
performance improvement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110201/1df852ea/attachment.pgp>