Add example for GLArea

[jmaargh]

This example uses a custom glium backend to allow glium to render to a GLArea widget. A somewhat-reusable glium_backend module is provided to handle the messier parts of this process.

This is based on #44, but somewhat refactored for more reusability, and developed/tested with up-to-date dependencies.

[GuillaumeGomez]

Please target the pending branch. We'll review it once done. :)

[jmaargh]

Re-targeted to pending :)

[EPashkin]

On windows it builds fine, but not works with "function was not loaded". I think that it not stopper, as glium tests fails for me too, seems my system missed something but I don't have time to investigate.

@GuillaumeGomez Please do "squash" on merge

[GuillaumeGomez]

Ok, cleaned up the commits. Reviewing now.

[jmaargh]

Fixed all issues.

Error "handling" is lazy, because I can't think of anything more robust that doesn't feel overkill for a simple example.

[GuillaumeGomez]

I fixed your commit history and you broke it all again :-/

[jmaargh]

Sorry, I think we're seeing different histories (presumably because you can't change the branch that's in my fork?) When you say "fixed" do you mean rebased to gtk-rs:pending?

[GuillaumeGomez]

No, I force-pushed on your branch. I'll let you fix it this time. :)

[jmaargh]

Fixed the history

[GuillaumeGomez]

Code looks good to me. I just need to actually launch it to confirm and then it's all good for me.

[sdroege]

What's the status here? @GuillaumeGomez ?

[GuillaumeGomez]

When closing the window, I get:

glarea: ../src/dispatch_common.c:863: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
Aborted (core dumped)

Could you fix this please? Once done I'll merge.

[jmaargh]

I don't remember seeing this before, but now I see the same assertion failure on exit (I have done a clean OS install since then, so who knows what could have changed).

Backtrace shows it's from epoxy not finding the context when Gl::DeleteVertexArrays is called as a result of self.triangle = None;. I've played around a bit and can't figure out exactly why the context seems to have disappeared before this point. In particular, the GL context is held by an Rc in the Facade object, which should still be in scope at that point.

This C++ example seems to suggest that you need to call (the equivalent of) connect_unrealize with after = false, but I couldn't get the rust API to let me do that (not even manually calling the underlying glib methods, mostly because their use is undocumented).

Without help, I'm not sure this is an error I can track down in a reasonable amount of time.

[sdroege]

This C++ example seems to suggest that you need to call (the equivalent of) connect_unrealize with after = false, but I couldn't get the rust API to let me do that (not even manually calling the underlying glib methods, mostly because their use is undocumented).

Right now you could use area.connect("unrealize", false, |args| { ... }) from glib::ObjectExt

[jmaargh]

I successfully used connect_local from glib::ObjectExt but just got the same result, with the same stack trace.

Somewhere after the window close request is triggered, something is causing epoxy_current_context_is_glx to fail to find a GLX or EGL context, when it was finding one fine before. As far as I can tell, the logic of this PR is sound -- unload GL resources on GLArea unrealize. The fact that something else within GTK/Glib/libepoxy/GTK-rs causing libepoxy to get confused before this can happen doesn't appear to be something this example can work around with anything other than hacks.