A few random thoughts after a very quick review of the changes:

1. Too bad this PR also contains the removal of VertexBuffer in drawables, makes the diff even bigger

2. What about sfml-window? sf::Window still creates an OpenGL context, so what happens with non-OpenGL rendering backends (Vulkan, D3D, software, ...)?

3. I think the rendering backends should be specified dynamically, rather than with a fixed enum. Even as a plugin. So that adding a new backend doesn't require to modify SFML core sources.

4. There are still GL stuff hanging around (FBO, push/popGLStates, ...), this should be abstracted and removed. If we allow the rendering backend to be specified dynamically, with no way to test (enum) inside sfml-graphics, this would be a sane way to force us to replace all these leftovers with proper abstractions.

5. So far the Impl classes seem to be a direct copy of former classes; we might be able to design a better API, with more stuff in base or concrete classes, and only a minimal set of features to implement in backends.

6. What happens with direct interaction between the user and the backend? Like exposing handles, etc., to allow direct OpenGL (or whatever) calls. Do we loose this ability or do you have a replacement solution? (I haven't noticed it while browsing the diff)

Yeah, I agree. Ideally, it should be possible to use any backend without even linking to any other. For example, if you want to only use DirectX, you shouldn't need OpenGL and vice-versa. I'm not sure how important it would be to be able to change them at runtime, but I'd say even just doing so only at compile time (of SFML) would be a big gain.

getRenderers() and setRenderers() are a nice dynamic approach, but this might make compiling SFML a pain and increase binary size as well as potentially required libraries. You'd either depend on DirectX, OpenGL, Vulkan, etc. or be forced to implement dynamic loaders for all of them.

I'd probably go for an optional standalone function bool sf::useGraphicsBackend<SubClassName>(args...); you may call before using anything SFML related, but it's not mandatory (I hate initialization/tear down calls, especially when trying minimal things in a code snippet). SubClassName would be a class derived from sf::GraphicsBackend providing all the necessary factories and/or regular functions. All this would do is create a new instance and assign it to a unique pointer. By default it would have a dummy backend that upon first call replaces itself with a platform specific default implementation (typically OpenGL right now) to avoid initializing OpenGL before using DirectX or similar things.

I'd go with GraphicsBackend over Renderer or similar, since this would allow one consistent naming scheme for the audio module, too.

Any movement on this?