I’ve spent time the last few months looking at OpenGL trying to grok how it works. And I wasn’t very successful. That was until I got 2 epiphanies. The first one is that the OpenGL API really is as bad as it seems. I had always thought OpenGL would be the best thing since sliced bread because everyone claims it’s awesome, from the early days up to recent times, where people claimedd it’ll be the future of graphics on Linux. So I somehow had higher expectations but it seems we’ll just switch from one ugly API to another one. (I’ll not get into ranting about why OpenGL is bad now.)
The other epiphany was related to glEnable (GL_BLEND) and some coce not calling it. Yes, that enables rather important functionality and yes, it’s off by default and no, the lib I was playing with did not enable it. After fixing that, I was able to have OpenGL-generated content in GStreamer pipelines. This video was generated using gst-launch:
The other thing I spent time on was making sure Cairo honours the thread safety promises it wants to give people in the future – ideally from version 1.10 onwards, but it looks like not all backends will achieve that. Before listing the promises, I’ll introduce a new object type in Cairo, the cairo_device_t. A device encapsulates the connection to the rendering backend and is roughly equivalent to a GdkDisplay. As we all know, this is usually not threadsafe by itself. But Cairo wants it to be. So it promises:
- Every surface can be used as a source in as many threads as one wishes.
- Any surface can be used as a destination in one thread at a time.
- Multiple surfaces sharing the same device can be used in multiple threads at the same time.
- Cairo rendering will not interfere while developers acquired the device and use it themselves.
Chris had spent time previously on ensuring that the image and xcb backends were threadsafe. I made sure the xlib and GL backends are now threadsafe, too. So you can basically start writing multithreaded applications using Cairo that use hardware accelerated rendering.
As my gst-plugins-cairo plugins are holding up pretty well stability-wise to the GStreamer pipelines I throw at it, I’ve managed to get gst-plugins-gl developers excited. Yay for more contributors! Now we “just” need to get all my patches merged and work on some performance warts and the future can be OpenGL.
6 comments ↓
OpenGL is alright if you can just use the core profile in 3.2+. Too bad that is not viable at all.
All I can think of is the candy: http://en.wikipedia.org/wiki/Spree_%28candy%29
(also, have you replied to the mail yet? ;)
I like your enthusiasm diving into OpenGL like that, however, I would say I lack the same courage.
You may have found this blog post (link below) on OpenGL vs DirectX where the author says that OpenGL has vendor specific extensions, bringing the latest technology from NVIDIA and ATI to OpenGL, something DirectX claims to be the only one to do. This intrigued me but I haven’t gotten around to put OpenGL into functionality.
There are various support libraries like GLUT and SDL but GLUT is somewhat limited, if you’re trying to use some advanced features like I am, and SDL uses Microsoft GDI for graphics by default so you will have to implement OpenGL by hand anyway.
Hope you continue on your quest.
Link to blog post:
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX
There are quite a few context creation libraries you can use. I use (C)SFML myself there is also GLFW. It’s a bit of a shambles really.
And SDL can create a OpenGL context.
Thanks, SFML is what I have been looking for, although compared to working directly with the OpenGL API, now it seems almost too easy…
I personally don’t use the high level stuff in SFML, I just use it to create a window and then write OpenGL.