Optimzation: code consolidation in drawCircle() #4302
Conversation
DedeHai
commented
Nov 22, 2024
DedeHai
commented
- replaced repeated function calls with loops
- saves about 600bytes of flash
- speed tradoff: drawing is now a tiny bit slower but insignificant in my tests
- saves about 600bytes of flash - speed tradoff: drawing is now a tiny bit slower but insignificant in my tests
What device have you tested it on? We need to make sure it doesn't pose an issue on the slowest supported devices. |
|
it won't pose any issue, as I mentioned, the slowdown is insignificant, tested on C3. The function is currently only used by ripple FX. |
| setPixelColorXY(cx-y, cy+x, col); | ||
| setPixelColorXY(cx+y, cy-x, col); | ||
| setPixelColorXY(cx-y, cy-x, col); | ||
| for (int i = 0; i < 4; i++) { |
There was a problem hiding this comment.
My suggestion would be to compact the "soft" Wu's algo (as you did), but keep Bresenham's code untouched.
Why: in some cases speed does matter, so I'd like to have the basic circle drawing as fast as possible. Also you did not save much code on Bresenham.
The "soft" algorithm is much slower any way, so I'd agree with you that making the code more compact here is better for readability.
There was a problem hiding this comment.
I ran a few more tests: there is no measureable difference in speed using the Bresenham's code, the "overhead" added by the loop is really small when comparing it to a setPixelColorXY() call. I got the exact same FPS with and without the changes using a modified ripple FX drawing about 100 circles. Also: there is no FX currently using the Bresenham's circle version.
With the Wu's algorithm, there is a slight drop in speed. Using the same modified ripple FX frame rate drops by 0.6FPS from 42FPS to 41.4FPS worst case.
There was a problem hiding this comment.
Also: there is no FX currently using the Bresenham's circle version.
There's an open PR that uses it.
softhack007
added
the
optimization
