>
> > > > I am useing clipping with FLTK 1.1.7 on Debian but=20
> > occassionally it stalls for a few seconds and I get these=20
> > messages on the console:
>
> That "stall" does sound suspiciously as if your program is off in a loop
> somewhere...
>
>
> > I put a counter in my draw function and found=20
> > that after severe damage the draw stack was quite deep. I=20
> > couldn't find the cause so instead I tried to forcibly limit=20
> > the redraws:
> > draw() {
> > static int depth =3D 0;
> > if( depth > STACK_MAX ) return;
> > depth++;
> > ..draw code
> > depth--
> > }
>
> > but then sometimes not all the damage was repaired. Do you=20
>
> That seems very odd - how certain are you that your push's and pop's
> balance?
>
>
> > have an idea how I can deal with this? Is this sensible:
> > ..
> > if( depth > STACK_MAX ) {
> > wait(X);
> > redraw();
> > return;
> > }
>
> Calling redraw() from within the draw method is unlikely to be useful -
> redraw() simply marks the widget as needing to be drawn again, but that
> flag gets cleared on exiting draw(), so calling redraw() from within
> draw() pretty much does nothing, in general.
>
> Calling wait() from within the draw method is almost certainly a Bad
> Thing, as it will suspend the fltk loop and prevent any fltk activities
> from happening.
>
> You are not calling the draw() method explicitly in your code, are you?
> You shouldn't ever do that, you need to let the fltk event loop call
> draw() for you - if you call it explicitly yourself, then the drawing
> context can be wrong and generally Bad Things happen.
>
>
> > Also in a previous post=20
> > (http://www.fltk.org/newsgroups.php?s1+gfltk.general+v6+T+Qcli
> > p+stack+overflow) it was said that "FLTK's clipping is only a=20
> > wrapper for the
> > underlying graphics subsystem, and such clipping is not very robust"
> >=20
> > Is it true the clipping is not very robust?
>
> No, the clipping is fine in general, I think you may have misunderstood
> what Jim Wilson was saying in his post: He was referring to the case
> (the example he gives is a CAD system) where the coordinate system for
> the image is much larger than the coordinate system for the underlying
> window system. Both X and win32 used +/-32768 as limits whereas a
> reasonable CAD system would probably have a much larger range... So, if
> you were to pass the "raw" CAD system coords to the fltk clipping, they
> might be cast to +/-32768, potentially causing points that are very far
> away (and should be clipped) to be wrapped onto the visible area. But
> this isn't a fltk peculiarity, it is a more general problem than that. I
> do not know if that is pertinent to how you render your image or not,
> however.hello, I am confident that I have the same number of push and pops and fortunately I don't call the draw function directly. I found that the stall was caused by scrolling, which would generate redraws faster than I could complete them and overload the clipping buffer as Greg suggested. Now I limit the updates when scrolling to avoid this problem. thanks for your suggestions, Richard _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
