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
|
Now I've tagged 0.15.rc.1 - feel free to merge this @softhack007 |
|
I would hold off with merging the optimization PRs to not accidentally introduce bugs. This PR serves one purpose only: code consolidation and flash optmization, it adds no features and fixes no issues. |
|
My plan for the GA release will be taken from the rc1 tag plus cherry pick of any fixes, not taking 0_15 |
|
got it. I have quite a few PRs pending that need to go through beta testing. Shall I merge those into 0_15 or will there be a new branch? |
|
You are good to go ahead and merge into 0_15 as this will be merged into main and then deleted as soon as the 0.15.0 GA release happens |
