Yes! For sure. I think we should seriously consider it. TLDR; there are a few concerns, but it could be the best way forward.
What do you(ses) think? Anyone want to try it out? I think we definitely could use something for what sdl-gpu does well. Which is mainly automatic batch rendering to reduce state changes, but also a rotation/scale API along with a nicer way to use shaders. - the author and other people have used it in various games, and it's a number of years old now. - People have used it on iOS and Android. Which both currently support OpenGL, and these are where you need performance most. - It's not in Debian, homebrew, Fedora or... (which is the same as 'is it stable/mature and packaged well?'). - The releases haven't been 'proper' and versioned yet. There's no .tar.gz with the version in its name for example. - it uses CMake (ya! for modern packaging). - It's marked as version 0.11.0 (ie. not stable or finished). - Currently it only supports OpenGL*[0] (which is still worthwhile). - there is a windows/appveyor CI, but it's been broken for five months. - it's mainly one author, but quite a few minor contributions. - there's lots of interactive tests, but no automated tests. - I'm slightly concerned it's too closely coupled to OpenGL, and some of this may leak through. The best thing about sdl-gpu is that it doesn't require you to batch up your drawing calls first. So people using the API in a naive way can also see performance improvements. However, (c)python has the high python function call overhead, so in some ways we still have to avoid non-batch rendering anyway. Some of these cons about packaging, and 'proper releases' could perhaps be contributed. However maybe the author doesn't want this(or yet), rather than doesn't know how or hasn't had time. There is a pkg-config script PR been open for two years without comment, so I'm a bit afraid the author doesn't care*[1 <https://github.com/grimfang4/sdl-gpu/pull/45>]. To be fair, that Pr is incomplete, so maybe the author just doesn't want to do this work, or wants to wait a bit longer before things stabalise... who knows? Or just wants to support CMake only. Perhaps asking the main author questions about it would be a good idea :) I'd feel more confident knowing someone I trusted who had used it, or someone experimenting with it more and reporting back any potential problems we'd have. Note, however that there are several 'draw 2D things faster on OpenGL' even done in python which are 'pretty good'. Including one I wrote (but that mainly worked at the sprite level). Other groups (renpy, kivy) seem to decide on 'hey lets roll our own!' where SDL is lacking. I think it's better to contribute to a shared solution with the rest of the SDL community. But perhaps it's worth us considering using or helping out one of the dozen python options? For example, some people already use some of the pyglet OpenGL drawing code on pygame. The SDL2 option is to try and help get a batched API into SDL2 itself. Then other backends would also be optimized that aren't using OpenGL. Remember that OpenGL is theoretically deprecated now. Things like Vulkan, Metal, Direct3d, and such. And there has been some work on that, and discussion on that for some time. But not much movement there. Note: sdl-gpu could(theoretically) be used from inside a SDL1 pygame :) If someone has some time, I feel like patching in the 10-30 required alternative function calls and just giving it a go could be a great first step. Which would be a search replace job with SDL_RenderCopy() into GPU_Blit(). Full list on the github page *[2 <https://github.com/grimfang4/sdl-gpu#conversion>]. Then we can better figure out the pros and cons... to determine if it's worth us using. To get around the problems with it not being packaged for Debian/Ubuntu/Etc... we could just make it an optional compilation for now. Then compile it ourselves in our binary wheels for these platforms, plus contribute towards packaging on Debian/Homebrew. Maybe it's even possible for us to compile it in, and have some sort of setting to enable/disable it. Not sure if that's possible, but that would be best. Open questions for me: - Is there someone I know who can try it out, and report back? - Will this be stable in the future and packaged well? Is this even an aim? - Will other backends be supported other than OpenGL ones? - Can we include it without tightly coupling ourselves to OpenGL? Will OpenGL leak out? - Can we compile it in optionally, so that people can opt in? - What other options are there for nice 2d OpenGL renderers? (pyglet, renpy, ...) - Can we get a confirmation from Sam/Ryan on if batch SDL2 rendering would be accepted? - Who will actually do this work? Does this work have to be done before a pygame 2, or can it come later? * [0] OpenGL 1.1, 2.0, 3.0, 4.0 OpenGL ES 1.1, 2.0, 3.0 * [1] https://github.com/grimfang4/sdl-gpu/pull/45 * [2] https://github.com/grimfang4/sdl-gpu#conversion
