> 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?
I only USHORT_MAX because this was the value that trigger the issue
for XUtf8DrawString (else it takes int as argument).
I will further tests for negative values (I have done none yet).
>
> 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...
>
You are right, I will see for a Tree Item solution, to avoid regression
somewhere else.
I do not know well enough fltk to have any opinion on this subject.
Just try to make my tests work for my own configuration.
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
