What to do with `SDL_RenderGeometry`

[damusss]

trafficstars

A lot of methods of Renderer use SDL_RenderGeometry (and the unfilled counterpart), but they only use it for triangles and quads. The thing is, sdl_rendergeometry has the potential of being one of the most performance-saving functions of them all, this is because if you combine it with a texture, properly set out texture coordinates and vertex positions you can literally render thousands (probably even millions) of tiles with a single draw call, removing the current bottleneck of the whole Renderer. The thing is, if it was that simple to add it, I wouldn't be making this issue. The issue is the layer from python to C. To use sdl_rendergeometry raw, we would need to convert the user's vertex data from python sequences to a c array, effectively iterating the very big sequence every frame, and all the speedup would be lost. The (pretty much) only solution would be an intermediate Mesh class, that stores the c array once (or when the mesh changes) so that the function is actually performant. So, then, the thing that needs to be discussed is: is it worth adding a Mesh class to pygame.render, explain the complexity of vertex data, texture coordinates and stuff in the docs, in a module that is supposed to offer a ready-to-replace gpu alternative to surface rendering? Summary: at this point, it would just be easier to use pygame.gpu. So, what do you think? Should we export SDL_RenderGeometry + Mesh, or should we correctly port pygame.gpu and let the user make that possible there? (more flexible with shaders)