Add simple opengl example #44

mjkoo · 2015-11-02T08:33:40Z

Added example of using a GtkGLArea from gtk-rs, currently the method of loading the required OpenGL functions is somewhat hacky (create an invisible window with glutin and use it's get_proc_address function to do the required name resolution). C examples tend to use a library called epoxy which does platform-independent GL function loading itself, having a similar functionality from within glutin would probably be better so you can still use the platform detection and library loading stuff without needing to actually construct a context/window. Unsure if this is possible with glutin as it stands currently, but after briefly perusing the code it does not seem to be.

GuillaumeGomez · 2015-11-02T09:33:56Z

Thanks ! Can you squash your first commit please ?

cc @gkoz

mjkoo · 2015-11-02T09:42:19Z

Sure, think I did that right?

GuillaumeGomez · 2015-11-02T09:43:51Z

Yup, that's good ! Thanks. :)

gkoz · 2015-11-02T14:13:04Z

Cargo.toml

@@ -5,6 +5,8 @@ authors = ["The Gtk-rs Project Developers"]

 [dependencies]
 libc = "0.1"
+gl = { version = "^0", optional = true }
+glutin = { version = "^0", optional = true }


Would it be a good idea to clamp down on the allowed versions a bit? What if glutin 0.5 removes WindowBuilder?

gkoz · 2015-11-02T14:24:29Z

Please add this patch to make travis build the non-dummy version of the example:

--- a/build.sh
+++ b/build.sh
@@ -5,7 +5,7 @@ set -e

 if [ "$GTK" = latest ]; then
        BUNDLE="gtk-3.18.1-2"
-       FEATURES=gtk_3_10
+       FEATURES="gtk_3_16 opengl"
 fi

 if [ -n "$BUNDLE" ]; then

…on required versions for OpenGL dependencies, add comment explaining glutin use in glarea example

mjkoo · 2015-11-02T16:30:32Z

Sure, hopefully this is better. I believe that the travis build failed as the example requires the modified GLArea stuff from the PR I submitted to the gtk repo (gtk-rs/gtk#185)

gkoz · 2015-11-02T17:58:23Z

The build succeeds now.

@tomaka has hinted on #rust-fr that this hack is likely to break. I'm hoping we'll get something more definite but it seems there might need to be a "THIS IS UNSAFE AND BROKEN" warning.

GuillaumeGomez · 2015-11-02T22:08:41Z

So here's the explanation from @tomaka:

it crashes because loaded functions depend of the context
the glClear function from context 1 might be not the same glClear function in context 2
if you're lucky and it's the same one, it will work
otherwise, it crashes

however, it's not "likely to break"
there is 98% chances that it'll work
but it's not clean

He also said that there was no "official" way to do it currently. :)

mjkoo · 2015-11-03T00:33:55Z

Yeah I agree it's a hack, not sure about the chances of breakage though. Looked through the libepoxy source, their approach basically comes down to picking between glXGetProcAddressARB / wglGetProcAddress / eglGetProcAddress / dlsym based on what platform it was built for (https://github.com/anholt/libepoxy/blob/master/src/dispatch_common.c#L651). libepoxy seems to be the "official" way to do this according to the gtkglarea examples from Gnome (https://github.com/GNOME/gtkglarea/blob/master/examples/gtkglarea_demo.c) Re-using glutin in this way is hacky, but comes out to pretty much doing the same thing, although it may be more comfortable if we just port this bit of logic from epoxy to rust to avoid abusing the glutin API in this way?

Either way to me it looks like GtkGLArea creates a context for you, but relies on you to correctly infer the correct way to load and use OpenGL functions after initialization, so the same type of logic with the same type of assumptions probably needs to go somewhere to make this usable.

Would you all rather I put in a large "HACKS AND BROKENNESS" warning, look at implementing libepoxy-style choosing between variants of *GetProcAddress, or hold off until there's a better way to achieve this in gtk or glutin/glium?

Somewhat of a side-note, what do you all / @tomaka think should be the way forward with regards to glium integration? I started looking at what would need to happen for that to work, looks like one would need to create a glium::backend::{Backend, Facade} implementation which wraps a GLArea at a minimum, but it's early days of me trying to grok how these parts of glium work under the hood.

gkoz · 2015-11-03T01:23:23Z

@mjkoo We'd be very happy if you investigated proper (or at least more reliable) ways of integrating GdkGLContext and glium. I feel, the example should wait until we find a better way or perhaps a conclusive lack of one. Let's take this to https://github.com/gtk-rs/gdk/issues/81

GuillaumeGomez · 2015-11-03T09:07:46Z

If we don't find a "perfect" / "official" solution, I'm okay with merging this PR if we add a complete explanation of what's going on in order to avoid losing people if some are interested in using opengl in GTK.

mjkoo · 2015-11-03T09:24:59Z

@GuillaumeGomez I think there is a better solution, as it stands this version isn't really suitable as it leads to conflicts between gl-rs's name resolution and epoxy's, more details in the discussion over at https://github.com/gtk-rs/gdk/issues/81

gkoz · 2015-11-04T13:52:46Z

src/glarea.rs

+
+        let window = Window::new(gtk::WindowType::Toplevel).unwrap();
+
+        let cell = Rc::new(RefCell::new(GLArea::new().unwrap()));


Any GObject already is a refcounted shared reference so you don't need to add another layer of that. Cloning will just add to refcount and all methods take &self.

gkoz · 2015-11-04T14:01:17Z

The realize signal receives a reference to glarea as an argument of type Widget, but it doesn't seem like there's a way to downcast this to a GLArea to invoke make_current, short of maybe extracting the underlying pointer and constructing a dummy GLArea wrapper around it (which seemed to be all sorts of wrong) hence this solution using Rc. Is there a better way to do this?

There will be a way to downcast objects once the object reform lands. I'll also look into making connect_* functions generic to hide that downcast under the hood.

mjkoo · 2015-11-04T14:02:32Z

Cool thanks, that makes sense now, Rc stuff removed.

gkoz · 2015-11-04T14:05:34Z

The amount of unsafe code makes me nervous. How much of it is due to the lack of glium integration?

mjkoo · 2015-11-04T14:10:37Z

Pretty much all of it, the epoxy stuff works essentially identically to the gl crate which also has a good amount of unsafe code due to passing pointers in and out of the raw OpenGL functions (see https://github.com/bjz/gl-rs/blob/master/gl/examples/static_triangle.rs for the example this code was based on).

gkoz · 2015-11-04T14:33:21Z

src/glarea.rs

+            let shader = Gl.CreateShader(ty);
+            // Attempt to compile the shader
+            let csrc = ffi::CString::new(src).unwrap().as_ptr();
+            Gl.ShaderSource(shader, 1, &csrc, ptr::null());


Hmm, it seems you're not required to use CString here because the function takes an array of lengths?
I'm somewhat allergic to CString because it's a popular source of accidental dangling pointers (not that you did anything wrong here).

gkoz · 2015-11-04T15:28:44Z

src/glarea.rs

+            if status != (epoxy::TRUE as GLint) {
+                let mut len = 0;
+                Gl.GetShaderiv(shader, epoxy::INFO_LOG_LENGTH, &mut len);
+                let mut buf = vec![0u8; len as usize - 1];


Isn't len "the size of the character buffer required to store the information log)" making len - 1 too short?

gkoz · 2015-11-04T15:37:03Z

Regarding the shader compiling functions, are the errors "static" in the sense that broken code won't compile and that's it, or can they depend on the hardware and the driver? In the latter case we might want to handle the error more gracefully than panicing.

Also it appears ~~GLArea::new~~ something just kills the process with "glarea: Couldn't find current GLX or EGL context" if a compatible GL implementation is missing. Could that be checked beforehand too?

…shader failure messages on panic

gkoz · 2015-11-04T15:50:17Z

src/glarea.rs

+                let mut len: GLint = 0;
+                Gl.GetProgramiv(program, epoxy::INFO_LOG_LENGTH, &mut len);
+                let mut buf = Vec::with_capacity(len as usize);
+                buf.set_len((len as usize) - 1); // Skip trailing null


I'd still be cautious when writing past the "official" length. And I just don't see why buf = vec![0; len as usize] would be inadequate. You can ignore the null byte later by taking a slice or letting CStr take care of both that and utf8 compliance:

CStr::from_ptr(buf.as_ptr()).to_string_lossy()

Okay that sounds good, will make that change. In general writing to a Vec within its allocated capacity should be "okay" though (for some definition of okay)?

mjkoo · 2015-11-04T16:04:36Z

Fixed the issue with the shader compilation error fetching and printing, I think I originally was having issues compiling that that caused me to change it, not 100% sure why but the previous version definitely was off by one (good catch!) and just ate the actual shader compilation error. Brought it back to be in line with the implementation from the gl example.

Shader compilation will depend on the hw and driver, not sure what would be a better way of handling it for this example application though?

That error message appears to be from libepoxy itself (https://github.com/anholt/libepoxy/blob/master/src/dispatch_common.c#L674), perhaps we could do a check against epoxy_gl_version before attempting to construct the GLArea? Not sure what that would report in the error case.

gkoz · 2015-11-04T16:24:33Z

Shader compilation will depend on the hw and driver, not sure what would be a better way of handling it for this example application though?

An ideal way could be along the lines of using idle_add to schedule a closure, that would show a message dialog with the error and then exit the app.

Panicing in a signal handler (which is a C callback) should be avoided at all cost because currently we just ignore the issue of unwinding across the FFI boundary ;)

gkoz · 2015-11-04T21:47:42Z

An ideal way could be along the lines of using idle_add to schedule a closure, that would show a message dialog with the error and then exit the app.

This might be too complex for its own good. If we defer the error message then the render signal needs to do some checking too. Perhaps showing the error dialog directly from the realize handler is okay.

GuillaumeGomez · 2016-03-04T22:28:54Z

@mjkoo: Hi! The gtk crate has well evolved. Are you interested in updating this PR to the last version so we can merge it? Having an opengl example in gtk-rs would be really awesome!

mjkoo · 2016-03-04T22:31:03Z

Sure, I'll take a look at it this weekend.

GuillaumeGomez · 2016-03-04T22:31:58Z

Great! Thanks a lot!

GuillaumeGomez · 2019-06-19T09:11:52Z

Closing due to inactivity. Don't hesitate to reopen once updated. :)

Add simple opengl example

2e30af6

mjkoo force-pushed the glarea-example branch from 2fc73a5 to 2e30af6 Compare November 2, 2015 09:40

gkoz reviewed Nov 2, 2015
View reviewed changes

Add patch to build.sh for travis to build opengl example, clamp down …

69b793d

…on required versions for OpenGL dependencies, add comment explaining glutin use in glarea example

Load opengl addresses from epoxy

14755ab

mjkoo force-pushed the glarea-example branch from fdd4b54 to 14755ab Compare November 3, 2015 04:21

mjkoo added 2 commits November 3, 2015 04:28

Add libepoxy binding generator

3fdfc85

Switch to using epoxy crate

cc2c4aa

mjkoo force-pushed the glarea-example branch from 1ef87f7 to 76237bc Compare November 3, 2015 23:57

Render a triangle with epoxy

9964286

mjkoo force-pushed the glarea-example branch from 76237bc to 9964286 Compare November 4, 2015 00:02

mjkoo added 2 commits November 4, 2015 07:22

Move gl initialization into realize signal handler

4d31ee7

Slightly more complex example with vertex colors

ab4dec3

gkoz reviewed Nov 4, 2015
View reviewed changes

Remove Rc wrapper of glarea

3831f55

mjkoo force-pushed the glarea-example branch from 77d199c to 3831f55 Compare November 4, 2015 14:19

gkoz reviewed Nov 4, 2015
View reviewed changes

Remove superfluous use of std::ffi::CString

874779d

mjkoo force-pushed the glarea-example branch from 240479e to 874779d Compare November 4, 2015 14:50

gkoz reviewed Nov 4, 2015
View reviewed changes

Fix off by one in shader compile/linker error handling, print better …

f5a396a

…shader failure messages on panic

gkoz reviewed Nov 4, 2015
View reviewed changes

Change error reporting to use CStr

8c2102b

Move shader compilation error into message dialog

bfdf0ef

mjkoo force-pushed the glarea-example branch from 9a45125 to bfdf0ef Compare November 5, 2015 02:26

Move to new epoxy api

5672176

GuillaumeGomez force-pushed the pending branch from 00dbf43 to 1ba0d7e Compare January 18, 2016 23:48

GuillaumeGomez mentioned this pull request Apr 28, 2016

Minimal example gtk-rs/cairo#74

Closed

GuillaumeGomez force-pushed the pending branch 2 times, most recently from d4e9930 to d45da29 Compare May 6, 2017 17:42

GuillaumeGomez closed this Jun 19, 2019

jmaargh mentioned this pull request Mar 1, 2020

Add example for GLArea #297

Closed

gkoz mentioned this pull request Nov 10, 2020

GLContext integration gtk-rs/gtk3-rs#94

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add simple opengl example #44

Add simple opengl example #44

mjkoo commented Nov 2, 2015

GuillaumeGomez commented Nov 2, 2015

mjkoo commented Nov 2, 2015

GuillaumeGomez commented Nov 2, 2015

gkoz Nov 2, 2015

gkoz commented Nov 2, 2015

mjkoo commented Nov 2, 2015

gkoz commented Nov 2, 2015

GuillaumeGomez commented Nov 2, 2015

mjkoo commented Nov 3, 2015

gkoz commented Nov 3, 2015

GuillaumeGomez commented Nov 3, 2015

mjkoo commented Nov 3, 2015

gkoz Nov 4, 2015

gkoz commented Nov 4, 2015

mjkoo commented Nov 4, 2015

gkoz commented Nov 4, 2015

mjkoo commented Nov 4, 2015

gkoz Nov 4, 2015

gkoz Nov 4, 2015

gkoz commented Nov 4, 2015

gkoz Nov 4, 2015

mjkoo Nov 4, 2015

mjkoo commented Nov 4, 2015

gkoz commented Nov 4, 2015

gkoz commented Nov 4, 2015

GuillaumeGomez commented Mar 4, 2016

mjkoo commented Mar 4, 2016

GuillaumeGomez commented Mar 4, 2016

GuillaumeGomez commented Jun 19, 2019


		let window = Window::new(gtk::WindowType::Toplevel).unwrap();

		let cell = Rc::new(RefCell::new(GLArea::new().unwrap()));

Add simple opengl example #44

Add simple opengl example #44

Conversation

mjkoo commented Nov 2, 2015

GuillaumeGomez commented Nov 2, 2015

mjkoo commented Nov 2, 2015

GuillaumeGomez commented Nov 2, 2015

gkoz Nov 2, 2015

Choose a reason for hiding this comment

gkoz commented Nov 2, 2015

mjkoo commented Nov 2, 2015

gkoz commented Nov 2, 2015

GuillaumeGomez commented Nov 2, 2015

mjkoo commented Nov 3, 2015

gkoz commented Nov 3, 2015

GuillaumeGomez commented Nov 3, 2015

mjkoo commented Nov 3, 2015

gkoz Nov 4, 2015

Choose a reason for hiding this comment

gkoz commented Nov 4, 2015

mjkoo commented Nov 4, 2015

gkoz commented Nov 4, 2015

mjkoo commented Nov 4, 2015

gkoz Nov 4, 2015

Choose a reason for hiding this comment

gkoz Nov 4, 2015

Choose a reason for hiding this comment

gkoz commented Nov 4, 2015

gkoz Nov 4, 2015

Choose a reason for hiding this comment

mjkoo Nov 4, 2015

Choose a reason for hiding this comment

mjkoo commented Nov 4, 2015

gkoz commented Nov 4, 2015

gkoz commented Nov 4, 2015

GuillaumeGomez commented Mar 4, 2016

mjkoo commented Mar 4, 2016

GuillaumeGomez commented Mar 4, 2016

GuillaumeGomez commented Jun 19, 2019