markov@cs.ruu.nl (Mark Overmars) (04/22/91)
When running the following program the black frame is not completely overwritten by the red rectangle. Why is this? Is this an error? Or should I draw the rectangle frame differently (e.g. in a different order). (I need this because sometimes I want to draw a frame around a rectangle and sometimes not. When drawing the rectangle without the fram it should of course erase the previous rectangle and the frame.) Mark Overmars #include <gl/gl.h> vv(float x,float y) { float v[2] ; v[0] = x; v[1] = y; v2f(v);} draw_rect(float x, float y, float w, float h) { color(BLACK); bgnclosedline(); vv(x,y); vv(x,y+h); vv(x+w,y+h); vv(x+w,y); endclosedline(); color(RED); bgnpolygon(); vv(x,y); vv(x,y+h); vv(x+w,y+h); vv(x+w,y); endpolygon(); } main() { winopen("TEST"); color(WHITE); clear(); draw_rect(50.0,50.0,100.0,100.0); sleep(20); }
kurt@cashew.asd.sgi.com (Kurt Akeley) (04/22/91)
In article <1991Apr22.081357.28429@cs.ruu.nl>, markov@cs.ruu.nl (Mark Overmars) writes: |> |> When running the following program the black frame is not completely |> overwritten by the red rectangle. Why is this? Is this an error? Or should |> I draw the rectangle frame differently (e.g. in a different order). |> (I need this because sometimes I want to draw a frame around a rectangle and |> sometimes not. When drawing the rectangle without the fram it should of course |> erase the previous rectangle and the frame.) |> |> Mark Overmars |> |> #include <gl/gl.h> |> |> vv(float x,float y) |> { float v[2] ; v[0] = x; v[1] = y; v2f(v);} |> |> draw_rect(float x, float y, float w, float h) |> { |> color(BLACK); |> bgnclosedline(); vv(x,y); vv(x,y+h); vv(x+w,y+h); vv(x+w,y); endclosedline(); |> color(RED); |> bgnpolygon(); vv(x,y); vv(x,y+h); vv(x+w,y+h); vv(x+w,y); endpolygon(); |> } |> |> main() |> { |> winopen("TEST"); |> color(WHITE); clear(); |> draw_rect(50.0,50.0,100.0,100.0); |> sleep(20); |> } The Iris Graphics Library uses different rules when sampling polygons and lines. Polygons are point sampled, meaning that only pixels whose exact center is within the area of the polygon are included in its rasterization. When the polygon edge passes through the exact center of a pixel, the results are tightly specified only if the edge is exactly vertical or horizontal. In these cases, the pixel is included for left and bottom polygon edges, and not for right and top edges. All that is guaranteed for sloped edges is that adjacent polygons neither share nor omit any pixels along their border. Lines drawn with Iris GL mode subpixel false (as is the case in your example) are interpolated with the well-known Bresenham algorithm. (Or in some cases with a DDA algorithm that approximates the Bresenham algorithm.) Because your example code does not modify the transformation matrix, it operates with the default matrix that accurately maps integer object coordinates to pixel centers. Thus the rectangle and the outline overlap along the left and bottom rectangle edges, and the line extends one pixel beyond the rectangles right and top edges. I confirmed this behavior on my VGX. -- Kurt