Yet More OpenGL Contexts

I’m finally moving my OpenGL code onto Linux (GLX) and it’s behaving quite a bit differently. The first is that threads and GLX seem odd - contexts can get locked onto threads, which is a pain (the thread holds the context, so you can’t just make the context current elsewhere), and there seem to be some precise rules about creation order. And don’t get me started on the X Window silliness.

So here’s where things gang awry: I’m trying to share, but there’s some odd rules about clinet versus server and multiple definitions of an ‘address space’ and also some odd mentions of the X screen having to match. Has anyone successfully shared textures on one context with a context on another screen (but the same GPU and graphics card)?

Meanwhile, I find on here: http://www.ogre3d.org/phpBB2/viewtopic.php?p=277749&sid=ce193664e1d3d7c4af509e6f4e2718c6 that they think that all commands should happen on the same Display connection. Does the juce OpenGL context address this? It does open a display connection and is that then shared? Should it be?

So looking at the Linux code, there seems to be a display member that all Linux juce code can share? Is that right? So I should actually use that member for my classes display connections rather than making my own: does that make sense?

Bruce

That does make some sense - the linux code does have a Display value that it uses throughout. I guess you could access the same thing from your app code, as it’s a global variable - you’d need to just declare it:

namespace JUCE_NAMESPACE
{
extern Display* display;
}

OK, thanks, I’m trying that. After the requisite 15 minutes of fighting to make it work in a class definition, of course. D’oh.

Bruce

Well, that didn’t take long. I guess the rule about using Display Connections across threads trumps this. I got a seg fault in Juce’s Linux windowing code in some xshm stuff, but I presume it because that uses the display connection I’ve been trampling all over. Oh well.

Have to get clever, I suppose.

Bruce