| 2011-05-11 07:21:01 |
Kamil Dudka |
description |
I am forwarding a patch written by John Sullivan and submitted to Red Hat bugzilla:
https://bugzilla.redhat.com/699472
John's original description of the patch follows:
While working on something completely different I bumped into several issues
with the libucil drawing primitives:
1) Although ucil_draw_rect clips to the viewport, neither ucil_draw_box nor
ucil_draw_circle do, which causes memory corruption and crashes when they
partially or completely fall outside the buffer.
2) The internal HLINE implementation looks like a partial attempt to optimize
for 8pp drawing on 32-bit word machines, but is called for 16/32bpp drawing and
even for 8pp gets the bounds checking wrong and can draw outside the line
endpoints
3) There is a separate partial attempt at a HLINE for 24bpp, but this isn't
used. Instead the box drawers simply loop, but ucil_draw_box gets the bounds
wrong and so never draws the bottom-right pixel of the box.
4) Although ucil_draw_line uses Bresenham, ucil_draw_circle uses trig which is
slower and grottier
This patch:
1) fixes draw_hline to handle 8/16/24/32bpp fully
2) refactors the colorspace support in draw_rect and draw_box so that 24bpp can
be handled the same way as 8/16/32bpp
3) changes draw_circle to use a DDA
4) since (3) makes filled circles easy, I've added a new function
ucil_draw_filled_circle
5) _box, _circle and _filled_circle now normalize and clip so they can draw
shapes that lie only partially within the viewport. |
I am forwarding a patch written by John Sullivan and submitted to Red Hat bugzilla:
https://bugzilla.redhat.com/699472
John's original description of the patch follows:
While working on something completely different I bumped into several issues with the libucil drawing primitives:
1) Although ucil_draw_rect clips to the viewport, neither ucil_draw_box nor ucil_draw_circle do, which causes memory corruption and crashes when they partially or completely fall outside the buffer.
2) The internal HLINE implementation looks like a partial attempt to optimize for 8pp drawing on 32-bit word machines, but is called for 16/32bpp drawing and even for 8pp gets the bounds checking wrong and can draw outside the line endpoints
3) There is a separate partial attempt at a HLINE for 24bpp, but this isn't used. Instead the box drawers simply loop, but ucil_draw_box gets the bounds wrong and so never draws the bottom-right pixel of the box.
4) Although ucil_draw_line uses Bresenham, ucil_draw_circle uses trig which is slower and grottier
This patch:
1) fixes draw_hline to handle 8/16/24/32bpp fully
2) refactors the colorspace support in draw_rect and draw_box so that 24bpp can be handled the same way as 8/16/32bpp
3) changes draw_circle to use a DDA
4) since (3) makes filled circles easy, I've added a new function ucil_draw_filled_circle
5) _box, _circle and _filled_circle now normalize and clip so they can draw shapes that lie only partially within the viewport. |
|
