This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9217 - Rockpaint line-drawing function
Attached to Project:
Rockbox
Opened by Christopher Williams (christop) - Sunday, 27 July 2008, 09:22 GMT+2
Last edited by Bertrik Sikken (bertrik) - Friday, 01 August 2008, 21:34 GMT+2
Opened by Christopher Williams (christop) - Sunday, 27 July 2008, 09:22 GMT+2
Last edited by Bertrik Sikken (bertrik) - Friday, 01 August 2008, 21:34 GMT+2
|
DetailsThe draw_line() function in Rockpaint draws down-right (and up-left) lines off by a pixel, and it uses a multiply and a divide inside the main drawing loops.
This implementation uses Bresenham's line-drawing algorithm, so it is probably much faster (no multiplies/divides), and it draws better-looking lines at all slopes. There is still room for optimization in this newer version, particularly in terms of memory (it uses 10 local integer variables). If anyone is also interested in a fast anti-aliasing line-drawing function, just ask me and I may port it to Rockbox. :) |
This task depends upon
Closed by Bertrik Sikken (bertrik)
Friday, 01 August 2008, 21:34 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as 18176, thanks.
Friday, 01 August 2008, 21:34 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed as 18176, thanks.
The first image (18139.png) is from revision 18139. All three of the lines were draw down and to the right (it makes no difference if they were drawn up and to the left instead). The top-left pixel stands alone in all three lines, and the bottom-right row of pixels is about twice as long as it should be. The middle line clearly shows this off-by-one problem, as I mentioned in my original post.
The second image (18139m.png) is my patched version. The lines look much better in this image. They are all symmetrical as much as possible (note that some pixels along a line could go either way -- up or down -- so not all lines will be exactly symmetrical). As a bonus, they were drawn faster than with the original code! To be honest, I don't actually notice any change in speed between this and the original code, but I'd be interested to see the results if someone else can perform a benchmark on both.