OSG and SDL

[scrawl]

A few thoughts on how to connect (or not connect) OpenSceneGraph and SDL.

With Ogre we're doing this: SDL creates a regular window without an OpenGL context. We pass this window to Ogre, via a platform-specific window handle. Ogre creates and manages the OpenGL context for the window using platform specific GLX/EGL/... APIs.
Problems with this approach:
- There is a bug; FSAA on Linux does not work.
- We can't support new display systems like Wayland and Mir, even though SDL supports them (Ogre would have to support them too).

Option 1

Same as what we're doing with Ogre: Have SDL create a window without context, pass the platform specific window ID to OSG via osg::GraphicsContext::Traits.

Option 2

There's an osgviewerSDL example in the source. It works by creating an SDL window with an OpenGL context, and then lets OSG render with that context.
Problems:
- Apparently this does not support multithreading due to SDL limitations. The osg Viewer is set to run single-threaded, which means it's not using all cores for culling and traversal (confirmed running the example only one core is used). Maybe these limitations are resolved in SDL2? not sure.
Advantages:
- New display APIs like Wayland and Mir can be automatically supported by us if SDL supports them.

Option 3

Drop SDL and use the OSG-inbuilt window and input handling functionality instead. The main reason we switched to SDL was to fix multi-monitor issues with Ogre, fullscreen input grabbing behaviour on Linux, and support hardware cursors. However, the OSG windowing implementation looks a lot more mature than Ogre's, so using it might be an option.

Option 4

Have OSG create the window and use SDL_CreateWindowFrom to pass it over to SDL. Might require some hacks to disable the OSG event loop.

[Chris]

I haven't looked terribly deeply into how OSG's update loop works and how to tie in SDL to it, beyond the basics, but here's my thoughts.

Option 2
There's an osgviewerSDL example in the source. It works by creating an SDL window with an OpenGL context, and then lets OSG render with that context.
Problems:
- Apparently this does not support multithreading due to SDL limitations. The osg Viewer is set to run single-threaded, which means it's not using all cores for culling and traversal (confirmed running the example only one core is used). Maybe these limitations are resolved in SDL2? not sure.
Advantages:
- New display APIs like Wayland and Mir can be automatically supported by us if SDL supports them.

What exactly prevents it from running multithreaded? AFAIK, X window events can only be handled on the thread that created the window anyway, and a GL context is effectively single threaded (a single GL context can't be made current on multiple threads at once; you need to create more GL contexts for other threads). I've noticed the ViewerBase class has methods to explicitly start threading and request threading behavior; perhaps those need to be called manually?

Option 3

Drop SDL and use the OSG-inbuilt window and input handling functionality instead. The main reason we switched to SDL was to fix multi-monitor issues with Ogre, fullscreen input grabbing behaviour on Linux, and support hardware cursors.

Not just fullscreen input grabbing behavior. It also had smarter grabbing behavior in general, which didn't completely block global keyboard shortcuts (like alt-tab), and released the mouse grab when losing window focus (though only if the app is processing events). These improvements were predicated on the use of relatively newer X11 extensions which OIS was being slow at adopting, and required some API changes to handle right. I'd really hate to go back to the old input behavior.

[scrawl]

What exactly prevents it from running multithreaded? AFAIK, X window events can only be handled on the thread that created the window anyway, and a GL context is effectively single threaded (a single GL context can't be made current on multiple threads at once; you need to create more GL contexts for other threads). I've noticed the ViewerBase class has methods to explicitly start threading and request threading behavior; perhaps those need to be called manually?

I've been curious about that too, but when I hacked the source code to change the threading model it just segfaulted.

Perhaps what is meant is restrictions with accessing multiple contexts from multiple threads, but in this case there is only one created context anyway, so it shouldn't be an issue.

http://forum.openscenegraph.org/viewtop ... 632d#12886

For this type of work you really should not use SDL, it really isn't
and API that scales well to handling things like threading or
multi-context work. The inbuilt features of osgViewer are much better
for doing this, SDL offers nothing extra - only restrictives relative
to what the inbuilt window support can provide.

Edit: with the multi-threaded model, OSG is running the draw calls in a secondary thread (osg::GraphicsThread::run). The context needs to be made current on that thread, which doesn't work with the GraphicsWindowEmbedded being unaware of the used context.

This should be pretty easy to fix though... so,

Option 5

Implement a subclass of GraphicsWindow creating the window and context via SDL. Implement the makeCurrent function so that multithreading works.

Not just fullscreen input grabbing behavior. It also had smarter grabbing behavior in general, which didn't completely block global keyboard shortcuts (like alt-tab), and released the mouse grab when losing window focus (though only if the app is processing events). These improvements were predicated on the use of relatively newer X11 extensions which OIS was being slow at adopting, and required some API changes to handle right. I'd really hate to go back to the old input behavior.

Who said anything about going back to OIS?

[Chris]

Edit: with the multi-threaded model, OSG is running the draw calls in a secondary thread (osg::GraphicsThread::run). The context needs to be made current on that thread, which doesn't work with the GraphicsWindowEmbedded being unaware of the used context.

I see. So Option 1 should still work in that case? In regards to FSAA not working, I think that was probably because we were using Ogre's externalWindowHandle rather than parentWindowHandle (due to intermittent crashes) so it couldn't set up the Window how it wanted for FSAA rendering. Maybe that won't be as much of an issue for OSG.

A custom SDL2-based GraphicsWindow could work, although I don't imagine it would be very easy.

Who said anything about going back to OIS?

I just meant in general. I don't know if OSG supports the X input extensions that SDL2 does for the saner grabbing behavior, but if not, I'd hate to go back to the old behavior.

[Ascent]

It'd be a good idea to support or use libs that support Wayland/Mir for future-proofing. I want to say that can wait, but someone could come along wondering why OpenMW doesn't work right now with the newest display tech that they're using because X11 is old and stale.

For input, I'm with Chris on the importance of handling common global key combos such as alt-tab and alt-enter. Because of the numerous DEs and window managers and OSes out there, it might be best to do this as abstractly as possible with SDL or with whatever OSG offers.

[slothlife]

I suppose that if Option 3 was buggy, then Option 5 would be more attractive, since the code using it wouldn't have to change much, ideally.

For Option 5, it looks like it would be necessary to implement a new WindowingSystemInterface and GraphicsWindow, and then replace the current WindowingSystemInterface via GraphicsContext. The event system is a little confusing to read through, but ideally the events can be extended to add support for joysticks, since that forum post indicated that joystick support is one of the few reasons to use SDL with OSG, and I don't see any sort of support for it natively.

Option 2 would mean less work to extend OSG, but if that breaks multithreading optimizations, then I suppose it isn't really an option.

[slothlife]

I now see what Scrawl was talking about with regard to OSG setting the thread model to SingleThread when you just embed the viewer in the SDL window, but by replacing the WindowingSystemInterface with a custom version you can get that back.

I have been tinkering around with OSG and SDL the past few days, and I've gotten a really rough SDL2 backend implemented. It's still buggy but I don't think it's as much work as previously though. With the threading model set to CullThreadPerCameraDrawThreadPerContext (AKA ThreadPerContext), it seems to be working OK in debug.

It seems that while we would have to translate events and post them to the osgViewer event queue, we probably don't have to implement any more than that, which is nice (so no worrying about extending events to add support for joystick).

Of course, Scrawl being the super-productive fellow that he is, I'm sure he's already done all of this.

[scrawl]

Nope, I haven't tried anything SDL yet. I want to get the NIF loader completed first.
If you've been following the IRC channel, Chris has also tinkered with SDL (and a MyGUI backend, by the way). He posted this, but you may want to get in contact with him for a more up to date version.

[slothlife]

Oh, cool. I'm on IRC now.

Just to correct myself from earlier - it seems that both viewers and windows have their own event queues, so posting events to the viewer wasn't entirely correct. What happens is that the viewer extracts events from its associated graphics windows each frame and processes those. If you post events directly to the viewer, then it will use its event queue's own _accumulatedState and result in oddities in things like mouse input. Posting directly to the window's event queue is what should be done instead.

[HiPhish]

I just love the hardware cursor in SDL2, it would be a shame if you had to drop it. Even at 60 FPS the difference between hardware- and software cursor is very noticeable. In an interface-heavy game like Morrowind it really makes a difference.