gfxdraw will be replaced by pygame.draw (157) #172
Description
Issue №157 opened by illume at 2013-01-09 18:34:43
Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)
gfxdraw needs improved documentation. The current documentation is very limited.
Along with this it may need API improvements, which means that the documentation will need to change. So the API improvements should maybe happen first, or at the same time as the documentation improvements.
To Do
- mark gfxdraw as deprecated in the docs.
- open issues for the missing functionality in pygame.draw VS gfxdraw.
- close this issue.
Related Docs:
https://www.pygame.org/docs/ref/draw.html
https://www.pygame.org/docs/ref/gfxdraw.html
Comments
# # MyreMylar commented at 2019-11-12 13:43:32
As far as I can tell the documentation for this module is now up to date and not noticeably worse than the other modules.
There is a vague mention of API changes in this issue as well, but I suspect a useful issue would need more specifics of what changes were desirable.
Recommend closing this issue as the main thrust of it has been resolved and perhaps opening a new issue about future changes to the gfx draw API (though there are a few issues already that cover a few specific enhancement requests such as # 1126)
# # illume commented at 2019-11-12 14:15:09
I guess we need to decide what to do with gfxdraw, and drawing in general. Currently gfxdraw hasn't had any changes for a while. However there is a SDL2_gfxdraw which supports using the new Renderer. However, since it is on sourceforge, it's a bit hard to contribute to.
Working on tests for all the existing drawing functions gives us a very nice basis to improve them and any future drawing work. Probably the gfx_draw documentation and API should just be the pygame.draw docs and API. On the other hand people probably rely on the gfxdraw API.
I'm not really sure how to progress. It would depend if there's someone who wanted to put in effort... but I'd guess concentrating on the pygame.draw module tests and docs is effort better spent. Someone may be able to ask the SDL_gfx author if they are interested in making it a more community effort based on github and building a community around it... however probably the author doesn't want to do that(they would have already right?).
So that's my opinion:
- concentrate on pygame.draw docs and tests.
- leave gfxdraw alone, unless someone wants to go to all the effort of making it a community project and make pygame.draw use it underneath.
# # MyreMylar commented at 2020-05-16 14:12:39
See @illume's post for how to close this.
# # illume commented at 2020-05-16 15:04:22
Alternatively, I think we should do this instead:
- mark gfxdraw as deprecated in the docs.
- open issues for the missing functionality in pygame.draw VS gfxdraw.
- close this issue.
Because reasons...
- SDL2_gfx still hasn't had any changes to it (since early 2018), and living on sourceforge I doubt it will pick up any time soon. SDL_gfx (which works on Surfaces) hasn't seen changes in even longer.
- No one has stepped up to finish gfxdraw (at least 2 months of work) in the last year (or in the last several years).
- there are lots of problems with the gfxdraw python bindings, and including SDL_gfx itself is problematic for linux distros, and we also need to maintain the code ourselves. Additionally there is a lack of test coverage and documentation.
- Putting extra work in on gfxdraw will distract from work on the pygame.draw API which is already better in many regards, and has improved a lot in the last year.
- there are some things which gfxdraw provides that pygame.draw doesn't. Like the textured_polygon, and bezier for example.
- pygame.draw doesn't work with the SDL2 Renderer. But neither does gfxdraw currently (it would need to include SDL2_gfx as well as SDL_gfx).
# # MyreMylar commented at 2020-05-16 15:12:43
Happy to do it that way instead.