Revisiting the OpenGL override for Foreign Windows discussion

SDL Development
#1

And, like clockwork, it begins anew. X-D

Per Icculus’ request, I moved this over to here from out of the Issues area over on GitHub.

Problem I have is that I have an externally provided Window, set up as a remote rendering to target. Needed to compensate for a problem where I can’t control windows stacking order on a Composited X11 window system for a mission critical design. (Like a dashcam system for LEOs…)

Why SDL? Well…the dev involved with one piece part opted to use an SDL based app to handle his video/audio playback and a few other things. Sensible, really- things were originally designed with this in mind. I’d like to actually keep SDL here and expand it’s use a bit so we can maintain this more cleanly with some of the things they have in mind.

The problem is that we need this with the Foreign Window interface. SDL_CreateWindowFrom doesn’t provide flags access and SDL sensibly does mostly hands-off operations on things there. There, however, needs to probably be a means for to which a more sophisticated dev hand it the info so that it can do sensible things like GLX/EGL contexts against the window…with the understanding they might be a bit on their own with it.

It’s been discussed several times in the past…can we strike up the conversation again and come to a bit of a conclusion this time without breaking the API?

1 Like
#2

Okay, I did a little research on this.

To be clear, the window being handed to SDL_CreateWindowFrom does not have a glX context created already? Does it have a glX-compatible Visual?

Part of the problem is you can’t change an X11 window’s visual after creation, afaict, and we can’t make a GL context later without a compatible visual.

As an example: SDL’s 2D render API asks that windows be created without the SDL_WINDOW_OPENGL flag, in case it ends up using something that isn’t OpenGL…and if it finds it needs this flag, it destroys the window entirely and rebuilds it, to get what it needs.

So there might be a way to make SDL_CreateWindowFrom notice that the window has a glX-compatible visual (although I haven’t looked into how) and set the SDL_WINDOW_OPENGL flag, but otherwise, we’re going to have a hard time making this work.

I’m open to ideas on how to get after it, but I don’t think this is a simple matter of adding a fix, hint or special-case API if the window isn’t already prepped for OpenGL when we first see it.

2 Likes
#3

Presume that it is prepped for things and it should have a compatible visual (Like I said about getting all the pieces if you break things…). I’ll own this is a bit of a screwball case.

I’ve got an engine that handles display of live video to a single surface that one and only ONE of the services processing that get to display. I then have an SDL app that a junior developer made that is intended to do select videos playback with the whole thing. Only one context active at any one given time, ensured by the framework. The problem was that he wrote it originally for the simple context, which is that we make our own window for each source and turn them on and off.

Thing is, that they hacked all of this in atop of a few other nasty, ill-behaved layers of code that gives us fits trying to ensure stacking order of the full-screen windows and compositing. It doesn’t want to honor something being forced to the background- so I came up with an equally nasty hack. X-D

Said hack requires the code the junior wrote to use the Window ID of the single rendering target surface that we can force to the back without inputs pulling the video feed surface to the top of stacking order. Which broke the app because SDL doesn’t like that (for good reasons…)

Let me dig into some of this alongside you. I’ve got it semi-working right now but have some start-up issues to getting it consistently setting up the visual the right way, etc. Thing is…it’s admittedly a big, fat Kludge on my end right now. I’d like to make it “right” if we can.