Replacing all GraphicsWindow implementations with SDL?

[rubenlg]

I've seen a few implementations of GraphicsWindowSDL2 on github already. For example here, although it's incomplete since it doesn't integrate event handling in an osgGA-friendly way. They seem to be comparatively much simpler than the core GraphicsWindows (not surprisingly, since SDL abstracts away a lot of platform complexity).

I remember reading something by Robert a while ago about SDL (SDL1) not being as good as OSG when it comes to managing windows, but it seems that this is no longer the case with SDL2 (aside: SDL3 is already in the works).

Given that the main purpose of OSG is rendering scenegraphs, and not creating windows, I think it could be a good idea to embrace SDL as the only way to create windows moving forward, deprecating and eventually deleting the existing options, for the following reasons:

• It reduces a source of multi-platform maintenance for OSG.
• OSG gets support for extra platforms. SDL officially supports more or less the same platforms as OSG, but semi-officially supports other platforms such as Nintendo Switch.
• OSG gets more features, such as setting the window icon, limiting window sizes, changing window opacity, creating modal windows, forcing windows always on top, signaling a drag&drop destination, etc.
• OSG gets extra event sources (gamepads, drag&drop, clipboard, sensors, etc).

On the downside, OSG gets another core dependency. The SDL API doesn't change all that frequently, and always has backwards compatibility layers to help with the transition, but it's still a dependency that has to be managed.

Alternatively, a GraphicsWindowSDL could become just another choice, enabled by default when building OSG with SDL2 support, and disabled otherwise. However, this option creates more maintenance work, not less.

Thoughts?

[robertosfield]

The OSG is in maintenance mode, backwards compatibility is king so making radical changes is not in order.

As for SDL, the problem has always been that is designed around a single window, single threaded model, which is fine for simple games but not at all appropriate for an API that support multiple graphics cards on multiple displays and running multi-threaded.

I don't know if SDL2 or SDL3 addresses this issue with single window/single threaded but I don't expect there is any value add over the inbuilt Windowing that the OSG has and is already well tested. Adding an extra external dependency when you already have code that works perfectly well is pretty perverse.

None of this precludes users liking to SDL/SDL2/SDL3 themselves and implementing their own Window using SDL or mixing and matching with the OSG's native windowing This is already possible - something I did plenty of for various projects to get gamepad and audio support etc.