Skip to content

What to do with SDL_RenderGeometry #3346

Open
@damusss

Description

@damusss

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)

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions