Description
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)