On 22.12.2011 09:56, David FLEURY wrote:
> On this issue, is this possible to replicate (somehting like) the
> clip_to_short method used in fl_rect.cxx into fl_font_x.cxx ?
> and use it each XUtf8Draw or draw string methods ?
>
> Something like:
> namespace {
> const int USHRT_MAX = 65536;
>
> int clip_to_short(int x, int y) {
> return ( x< 0 || x> USHRT_MAX || y< 0 || y> USHRT_MAX );
> }
> }
>
> and in the 2 draw and rtl_draw and a clip check
> if (fl_gc&& !clip_to_short(x,y))
>
> (line 335, 341, 350)
Well, maybe, something like that...
Question: why do you use "USHRT_MAX = 65536" instead of SHRT_MAX (32767),
as it is in fl_rect.cxx, as you mentioned above? X coordinates can be
negative, so they are signed shorts AFAICT. Am I missing something?
The check you propose is probably not what we want, because this only
checks the starting coordinate of a string. If this is in legal space,
the remaining parts of the string can still be out of bounds and wrap.
I wrote that clipping code in fl_rect.cxx, and I used it only for
horizontal and vertical lines, since everything else may be difficult
to handle (there can be all sorts of objects like circles near the
boundaries of the coordinate space, or they may be too big to fit),
not to mention (rotated) text. To be correct, we'd have to measure each
text before drawing - I believe this would be too expensive.
I suppose that you should implement clipping (i.e. don't draw objects
out of the widget's visible area at all) in the widget's draw method
rather than relying on the basic draw functions doing the clipping.
That said, coming back to the original part of the thread: since this
concerns Fl_Tree, this could be done best in Fl_Tree's implementation.
IIRC, Greg mentioned that he intended to do this for performance
reasons anyway, so this would avoid clipping at the drawing functions.
If you still feel that clipping should be done at the drawing level,
please file a STR (fltk.org/str.php), so that we can keep track of it.
However, AFAICT it's much more complicated to do it correctly, so we
might not implement it in the near future...
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
