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
