I think fl_rect should be fixed to draw the right thing when the line width is not zero. Speed is not an issue, except for one if, it would draw the 0-width ones identical to today.
It should act as though you drew a closed rectangle along the edges. The main reason the corner is broken is that we are not telling Quartz to close the shape. Fabien Costantini wrote: > Albrecht wrote: >>> 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? > > Or solution #4 (or #3 a bit developed) : > 1. Existing fl_rect() and fl_rectf() would be renamed: > fl_fast_rect() and fl_fast_rectf() and would be documented as gui low > level, fast drawing primitives. > 2. Deprecated fl_rect() and fl_rectf() would call fl_fast_rect() and > fl_fast_rectf() in 1.3, they would be removed later. > 3. fl_draw_rect() and fl_draw_rectf() would feature rich line style options. > Of course, it would be really slow to render, but would be used in more > demanding 2d graphics code, as opposed to graphical user interface faster > rendering primitives. > This would be unambiguous, full featured, and still simple to code as all the > code already exists today. > Fabien > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
