>> 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()
Ahh, I should have RTSL'ed to see what was really going on.
Good points too after that.
Though certainly widget programmers shouldn't have to RTSL,
so I guess we have to flesh out the docs as problems are
encountered.
Sounds like the docs should really just say don't try to
mix fl_line_style() with fl_rect(), and that the intended
purpose of fl_rect() is to guarantee single pixel lines
for pixel perfect "widget-accurate" purposes only, and it's
/not/ just a convenience function for drawing rectangles
(as eg. four fl_line() calls) which one might otherwise assume.
>>>> Theoretically, both should look the same (though I guess it depends
>>>> which side of the dimensions the extra pixel thickness should go for
>>>> a two pixel thick line), but on all platforms you can see there's
>>>> flashing going on.
>>>
>>> No, they shouldn't, because...
>>>
>>> According to the docs, fl_rect() "Draws a 1-pixel border inside the
>>> given bounding box." Emphasis on "1-pixel" and "inside".
>> Since there's no docs to the contrary, yes, I imagine the
>> implication is fl_line_style() should grow the extra pixels
>> inward from the xywh perimeter to follow that rule.
>
> Which extra pixel? It's a "1-pixel border" ;-)
Yes, I see where you're coming from now.
I did purposefully miss your emphasis on 1-pixel border, because
in the context of fl_line_style() and the apparent behavior,
it seemed like that was only being mentioned to indicate the
"default" behavior.
But now I see that maybe the docs are trying to say 1-pixel
rectangles are the only intended use for this function.
Considering the OS specific rectangle calls that are being used,
(and not four fl_line() calls), I guess the docs should warn that
if you /want/ to draw thick rectangles, use the equivalent
fl_line() calls, and not fl_rect().
I'm led to wonder if even dotted lines are supported here..
possibly not.
> I don't know if this is for performance reasons (modifying the graphics
> context every time might be expensive) or a simple omission. We
> certainly need comments of the previous authors about what was intended
> with this code and why.
>
> Solution #1 (the documentation is correct, the code is wrong): Save the
> line properties in static variables (like fl_quartz_line_width_ for
> Quartz) and change them in the graphics context only if they differ
> (because this would be an "expensive" function call) and reset them
> after the drawing function.
>
> Solution #2 (the code is correct, the documentation is wrong): Correct
> the docs to say that fl_rect()'s line width depends on fl_line_style()
> and try to document the behavior exactly (as far as possible), and maybe
> also adjust the drawing to draw the additional pixels always _inside_
> the fl_rect() as documented.
>
> Solution #3... A mix of both?
Right -- I've referred the STR to this thread, so hopefully
these details can be fleshed out a bit.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
