Richard Penman wrote:
> thankyou Greg. 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--
> }
I can't see that being good, because that would mean your widget
would only partially draw sometimes.
The question is why are there so many levels of depth needed;
are their widgets-within-widgets to that many levels of depth,
or is there some kind of recursion going on in your draw() routine?
The above coding pattern would seem to imply that your "..draw code"
is recursive, either calling its own draw(), or that it can be a
child of itself to many levels of depth. In which case try popping
the stack before you recurse, so that it doesn't "build up" during
recursion.
> Also in a previous post
> (http://www.fltk.org/newsgroups.php?s1+gfltk.general+v6+T+Qclip+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?
Maybe Jim's referring to the fact that clipping is limited to
rectangular regions only, i.e. doesn't support diagonal,
circular, anti-aliased, or arbitrary regions.
I've never needed these myself, as when I work with FLTK I understand
everything is implemented as rectangular regions. So in that respect
clipping works fine and I've never needed more from it.
I have to say I'm not sure why STACK_MAX is apparently hardcoded
to 10; it seems like that's an oddly small hard coded limit.
I could see where experimenting with some kind of recursive widget
that has special needs for clipping would trip on that pretty fast.
In which case maybe the right thing to do is recompile FLTK with a
doubled STACK_MAX value..?
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
