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.
Am I right in thinking that the line directions determine which
side of the line the 'extra pixel' falls on for the line style?
For odd line thickness, the integer math comes out nicely;
a line thickness of 3 means an extra pixel will appear on
either side of the line.
But a line thickness of two means a choice has to be made
by the line algorithm to place the extra pixel on either
one side of the line or the other.
I'd assume if fl_rect()'s four lines are drawn with this
in mind, such that when drawn inside a clipping region,
you'd get a 'consistent' line thickness clipped off around
all edges.
But it appears that's not the case with the current behavior,
which should either be documented, or if it's controllable,
made more consistent.
Documentation for fl_rect() should maybe be added, along the
lines of what FLTK can guarantee, eg:
fl_line_style's whose line thickness is >0, the line
thickness will grow around the pixel centers of the
defined rectangle.
For cases of line thickness where the value is even,
the integer math [WILL or WILL NOT?] guarantee the
extra pixels will always fall [INSIDE? OUTSIDE?]
the rectangle's perimeter.
It seems we should say something, otherwise folks are left
to come up with whatever they think the behavior should be,
and will be surprised when it's not.
>> 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.
To do that though, I imagine fl_rect() would have to check
to see if the line thickness is something other than the default,
and adjust the lines if so to draw inward. That might be tricky
though, if integer math makes this unpredictable.
Or, maybe we should just add a comment to the docs saying:
fl_line_style()s other than the default of zero
may cause the line's edges to fall outside the xywh area.
> As I read this, Jane's original code is wrong, and the correct fix is to
> draw two fl_rect()'s, as she did already :-) .
Right; in my first reply I suspected fl_line_style() was the problem,
and recommended to instead leave its value alone, and just draw
two fl_rects.
In my second reply, I focused more on the problem of the odd
line style behavior where the line thickness was different for
the top and left edges only.
> Although it is documented "If you change this it is your responsibility
> to set it back to the default using fl_line_style(0)", it is not
> completely clear (for me) if this means that you must _reset_ the line
> style before calling fl_rect(). If this is true, then everything else is
> undefined behavior, and FLTK is right. ;-)
Mmm, I only read that one way: "when you change the line style
for your drawing, don't forget to set it back to 0, or it will
remain in effect, affecting other fltk widgets outside your
draw() function."
In other words, FLTK will not reset the line style to zero
whenever your draw() function completes; you have to reset it.
Since the above comment is from fl_line_style()'s docs
(and not fl_rect()'s), I don't think there'd be any other
way to read it.. maybe I'm missing something.
I think it's safe to assume fl_line_style() affects all line
drawing functions, including convenience functions like fl_rect()
(which probably just draws four fl_line()s internally)
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
