> > > I am useing clipping with FLTK 1.1.7 on Debian but
> occassionally it stalls for a few seconds and I get these
> 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
> that after severe damage the draw stack was quite deep. I
> couldn't find the cause so instead I tried to forcibly limit
> the redraws:
> draw() {
> static int depth = 0;
> if( depth > STACK_MAX ) return;
> depth++;
> ..draw code
> depth--
> }
> but then sometimes not all the damage was repaired. Do you
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
> (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
> wrapper for the
> underlying graphics subsystem, and such clipping is not very robust"
>
> 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.
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
