Description
NOTE: I have already written the code for what I'm about to discuss (I can adjust it of course)
NOTE II: I would not add them to pygame._sdl2.Renderer, but to pygame._render.Renderer, as pygame.render is the C implementation and future stable version of it. That module is still incomplete as of today, but this methods do not require Texture or Image, meaning they would work even with the incomplete porting status. Concerns about adding New API before the porting is done are understandable so we can discuss them here.
The current renderer methods use the following: SDL_RenderLinesF (or similar name) and SDL_RenderGeometry, but they limit their potential to triangles or quads. There is no way to draw a polygon or lines with the Renderer (you can draw the outline by doing an unhealthy amount of single line calls, which, of course, isn't optimal) even tho SDL has some functions perfect for it. Also, pygame.draw can do that, so it would be cool not to make them too different. Besides from adding shortcuts, we should also give to the user the full flexibility of SDL functionality, otherwise it would fail at being a good wrapper.
When it comes to the outline, it's pretty straight forward. You just use draw lines with the corrisponding SDL function. To avoid having a duplicate method with almost the same code, I think the Renderer.draw_lines should take a closed boolean flag, similar to pygame.draw.lines(closed=True) which effectively turns some lines into a polygon. If you don't like this, and would prefer to have a draw_poly aswell, tell me why under this issue and we can discuss about it, but for the time being it doesn't seem useful.
When it comes to filling it, there is no problem with lines (you don't fill a line) but there is a problem with polygon. The fact is we have to use the SDL_RenderGeometry to do that, just like fill_quad does for example. Except that the basic algorithm to form the sub-triangles of the polygon does not work for any sequence of points. Non-convex polygons require a more complicated algorithm. A convex polygon (asteroid-like) instead only requires a simple triangle fan algorithm and the result is flawless. If you want, I can search the papers for the algorithm and implement it in C, it's really not a problem, I might have fun with it, but the function I implemented for now uses the triangle fan, and this is why I'd like to name it fill_convex_poly, to be very clear. If we also add A works-with-any-polygon method in the future, it can be called fill_poly, which would be slower to handle convex polygons (as the other algorithm works faster) but can draw them all. What do you think? Does it make sense?