[Cogl] Cogl in Python

[Robert Bragg]

On Sun, Apr 8, 2012 at 5:16 PM, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 04/08/12 12:54, Robert Bragg wrote:
>>
>> On Apr 8, 2012 3:33 AM, "Martin Owens" <doctormo at gmail.com <mailto:doctormo at gmail.com>> wrote:
>>>
>>> Hey Cogl Devs, (Just Robert and Neil?)
>>>
>>> Version: libcogl9 1.10.0 / gir1.2-cogl-1.0
>>>
>>> I'm using Cogl using gobject introspection, in conjunction with Clutter.
>>> But I'm having a problem using materials. Trying to do anything with
>>> Cogl objects causes a segfault, anything at all. Which means things
>>> like:
>>>
>>> m = ClutterTexture.get_cogl_material()
>>> Cogl.set_source(m)
>>>
>>> works ok, but:
>>>
>>> m.set_color4ub(255, 255, 255, 128)
>>> Cogl.Material.set_color4ub(m, 255, 255, 255, 128)
>>> print m
>>>
>>> Cause SEGFAULTS in Py_GetAttr, recursive_isinstance,  PyFile_WriteObject
>>> respectively.
>>>
>>> I did manage to workaround the SEGFAULT caused by cogl trying to unref
>>> the material after it had existed in python. Using the `del m` to remove
>>> it completely from the python namespace stops the odd duality.
>>>
>>> Literally looking at cogl-material in the wrong way causes it to blow up
>>> in ones face. I wonder what Clutter does that Cogl needs, maybe some
>>> sort of cooling rod ;-). Any ideas either working around these issues or
>>> trying to debug them using gdb, I'd be open to tracking through them.
>>>
>>> Best Regards, Martin Owens
>>
>> Hi Martin,
>>
>> We've only recently started looking at language bindings for Cogl so I'm sorry that at the moment things aren't as simple as you might wish if you aren't using C.
>>
>> The thing is Cogl doesn't use gobject and so gobject intospection doesn't really work for us to create language bindings. We have a few boxed types really just to allow clutter's api to expose CoglMaterial and CoglMatrix but it's not surprising to me that they fall apart if you give them a funny look.
>>
>> Because our api doesn't follow a lot of classic gobject api patterns I'm not really sure how far we can get using gobject introspection for full cogl bindings. I'm not sure that just shoe horning cogl through g-i by creating dummy boxed types is going to have a great result. It might give us bindings a bit quicker than doing them manually but I think perhaps they would be a bad fit.
>>
>> I was recently hoping to at least try and use the .gir data as a basis for v8 bindings I was working on but really hit a brick wall with using the scanner to get the data I wanted and at this point I'm thinking it will just be simpler for us to use somthing like c2xml to extract an initial markup for our api and extend that with annotations by hand for our specific use cases.
>>
>> Similarly for java bindings Neil found a pretty elegant way of marking up the cogl api using java annotations for the front-end api and then the compiler has some tricks to programatically access those annotations so we can generate final bindings.
>>
>> Since I also find it disapointing how locked away the gtk-doc annotations we have in Cogl are currently I've recently been looking at doing a one-off export of all our gtk-doc data into a simple xml schema which we can combine with the markup of the prototypes and I'm interested to find out if that would be good enough for us to then generate our bindings and html documentation from.
>>
>> I guess that this is perhaps not the answer you were hoping for but I hope it gives some insight into what we've been thinking and toying with recently.
>>
>> If there is a strong interest in g-i based bindings specifically then certainly we'd be open to ideas and help figuring out if it would be workable, but at the moment I think perhaps Cogl breaks too many assumptions about gobject based apis that it's possibly not the right tool to try and use for us.
>
> FWIW, i created working D bindings from the g-i data, though this patch
> was needed at the time:
> http://lists.freedesktop.org/archives/cogl/2012-February/000019.html

right, I remember seeing this but sorry I forgot to reply to this at the time.

One thing to note here is that we should probably try and generate a
separate Cogl-2.0.gir file here instead of exposing the experimental
2.0 api through Cogl-1.0.gir.

When I tried to generate a Cogl-2.0.gir file the other week though the
.gir file was missing lots of api even though the necessary headers
were being included with the right defines. My assumption was that
because we are missing _get_type() functions for things like
CoglOnscreen that's why it wasn't outputting corresponding classes.

>
> The result looks like this: http://repo.or.cz/w/girtod.git/blob/HEAD:/gtk2/cogl.d
>
> Using the GI files made this task relatively simple, w/o them it probably wouldn't
> have happened (it was basically a side effect of doing bindings for clutter).

My first concern with autogenerated g-i based bindings for Cogl would
be that they probably don't consider the interface-oriented api design
patterns we have been trying to follow with its design.

For example CoglFramebuffer is conceptually an interface that's
implemented by CoglOnscreen and CoglOffscreen and CoglTexture is
conceptually implemented by CoglTexture2D, CoglTexture3D and
CoglTextureRectangle etc. With our language bindings we would like to
ensure those relationships don't get interpreted as class inheritance
instead. We want to maintain the freedom to later use the
CoglFramebuffer interface with other objects without requiring it to
be in the class heirachy. One hypothetical example is that we might
want to allow the framebuffer api to work directly with CoglTextures
without always needing the CoglOffscreen api.

Although I can see that by exposing gobject introspection data it's
possible that we will get some bindings for "free" (and it looks like
these D bindings are one such example) I think that because the Cogl
api isn't a stereotypical gobject api we need to be careful that the
bindings we create take that into account.

kind regards,
- Robert

>
> artur