Albrecht Schlosser wrote: > Greg Ercolano wrote: >> Albrecht Schlosser wrote: >>> Yes, really interesting, nice demo. >> >> Yes, it appears that fl_rect() was not piling on the extra pixel >> thickness in a 'predictable' way; the extra pixel was ending up >> on the /inside/ of the rectangle for the right and bottom edges only; >> for the other two edges the extra pixel ended up /outside/ the >> rectangle, causing those to get clipped, making a lopsided rectangle. >> >> I'm imagining fl_rect() is implemented as four fl_line() calls, >> so I'm thinking fl_rect() gets to define the direction the lines >> are drawn. > > It's implemented with whatever drawing primitives the OS provides > (src/fl_rect.cxx), and there it happens to become different: > > USE_X11: XDrawRectangle() > WIN32: MoveToEx() + 4x LineTo() > APPLE_QUARTZ: CGContextStrokeRect() > > Interesting point: For Quartz antialiasing is switched off explicitly, > if (and only if) the current line width is 1.0f (I'm guessing this from > reading the code, but it seems to be obvious). [BTW.: And it is > unconditionally set to true afterwards, which might be another bug, if > it was false before.]
For better testing I added a check button to draw an additional black 1-pixel line over the existing line drawing test in test/line_style.cxx (svn rev. 6595). So you can see where the additional pixels (with width > 1) are drawn. Enjoy :-) Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
