[Cogl] Cogl in Python

Tue Apr 10 13:52:21 PDT 2012

[misclicked reply-to-sender; sorry for the duplicate]

On 04/10/12 20:03, Robert Bragg wrote:
> > 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
I guess exposing it as gobject "interfaces" wouldn't be possible? (if that
would have been the case my generator would have "mixed in" all the
"interface" methods into the appropriate classes)

I have one line in the D crate example marked with XXX because of the cast:
> >   fb = cast(cogl.Framebuffer*)onscreen; // XXX
and now thanks to your email i know why it's needed, and also how i could
fix it - thank you.
Until now i have managed to avoid having *any* substantial modifications
to the bindings - it all straight translations from the GI data, it would
be good if things could stay that way, but if that's not possible i guess
synthesizing the "interfaces" could be an option.

artur

PS. I don't think i've ever used cogl.Material - if there exists some simple
self-contained example that uses it i could try it from D using my bindings.
But these parts of GI indeed look sane, so the problem may be elsewhere.