[Cogl] Cogl/Clutter + Existing OpenGL Libraries

[Robert Bragg]

On Thu, Mar 22, 2012 at 8:33 PM, Jeremy Moles <jeremy at emperorlinux.com> wrote:
>
> Hello all (I've cross-posted this to Clutter as well, just in case).
Hi,

>
> I'm trying to get Clutter/Cogl to function within an existing OpenGL
> library, particularly OpenSceneGraph. I've been asking in the IRC
> channels about this, and have gotten a lot of informative responses, but
> unfortunately it's mostly overviews on how one "might" go about doing
> it. This would probably be fine for someone with more experience, but
> I'm actually looking for some example code (if possible), particularly
> from anyone else who might have tackled the same problem.
>
> Here's what I know so far:
>
> 1) Cogl has a gles2 branch that tries to address this issue somewhat.
> However, it only works with GLES2 (and you cannot simply fire of OpenGL
> drawing commands, you need to invoke them through a vtable). I cannot
> verify if GLES2 is even supported on my laptop machine (with NVidia
> hardware, which 90% of my users will be using), so I wasn't able to get
> far with this at all.

This branch is only a couple of weeks old so I'm afraid that you're
probably only the fourth person to have reviewed this branch, besides
Neil, Tomeu and myself and so there is definitely work for us to do to
make this more easily usable for this kind of problem.

I'm not aware of Nvidia supporting GLES 2.0 on their desktop hardware
but the plan here was that we would support GLES 2.0 via Cogl but
virtualized on OpenGL. The only fiddly thing about doing this is
hiding the differences in glsl between version 1 and glsl version 1.1
but still that's been done before by several projects so shouldn't be
a big problem and there may be code we can borrow. Initially just
allowing the use of "#version 100" could even be enough for most
applications. Obviously this isn't very helpful information for you
since you want a solution now, but at least I hope it clarifies that
this approach would eventually be fine on Nvidia.

>
>
> 2) OpenSceneGraph is perfectly fine with not ever setting up a window or
> being aware of an existing context; it can be used entirely under the
> assumption that these things have already been handled for it. In fact,
> this is how OpenSceneGraph functions inside Qt/Gtk widgets, SDL, etc.

This is basically what the gles2-context branch is for, to give you an
"existing context" that you can do whatever you like with, that will
be compatible with Cogl's own internal context, setup so you can share
textures between the contexts and provides an api to switch between
these extra contexts and Cogl's internal context.

I suppose ideally for your use case you might prefer access to full GL
instead of just GLES 2 but really that makes things quite a bit more
awkward for us to support so for now we are only planning on adding
gles2 integration support. Potentially we could do a similar thing for
full GL although it wouldn't be as portable.

>
>
> Again, there have been a few theoretical things mentioned on IRC by the
> main developers (bpeel, ebassi, rib, etc.), but I figured I'd look for
> some example code to help out. I understand traditional OpenGL (and even
> using glX to some degree), but Cogl abstracts so much away it's a bit
> beyond my current understanding trying to manipulate it in ways it
> doesn't easily support.

One problem here is that this is very recent work (only done in the
last few weeks) so the only example we currently have is the one
you've probably already seen that explicitly accesses the gles 2 api
via the vtable from cogl.

I think a thing that could help you is providing a shim libcogl-gles2
library that would provide you the standard glClear and glDrawArrays
symbols etc that osg can then link against so you don't have to worry
about jumping through the vtable. I've made a start on creating such a
library today so hopefully I can push this for you to take a look at
soon.

Besides having the libcogl-gles2 api something else we need to
consider here is that Clutter doesn't provide a way to have an
offscreen stage that renders to a texture which it sounds like you
want so that you can pull a clutter scene into osg. We probably need
to add a way to create a stage from a CoglFramebuffer.

I'm sorry that integration isn't straight forward at this point (it's
basically not supported at all without using hacks currently). I think
it is actually a pretty awkward problem to integrate orthogonal
components that use OpenGL, even the examples you give above of gtk,
qt and sdl I think are examples where osg is still basically the only
component that's interacting with opengl.

We are interested in supporting gles2 integration and at least at the
Cogl level we have been actively working on this recently, but it's
true that we still aren't quite there yet. Hopefully your input can
lead us to a usable solution for you though.

In the short term there is the possibility of integrating using some
hacks that may not be entirely future proof and will be limited to a
single window system api such as glx or egl which Neil and I were
talking through earlier. If a quick, somewhat hacky approach could be
ok for you to start with then Neil can probably give you some pointers
here?

kind regards,
- Robert

P.S I'm on holiday for this next week so sorry if I don't respond to email

>
>
> Thanks!
>
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl