> On 02/05/2010 08:26 AM, Jose Marcelo Auler wrote:
>
> > I've made a key generator in order to automatic test stability of my
> > software, and turned out that Fl::run() returns(exits) after a while. I
> > first
> > tried a key generator of 20Hz, and it takes a lot of time to be in this
> > condition, but with 50Hz(50 keys per second) it's very quick.
>
> Hm... Sounds like a circular keyboard buffer has overflowed and something (in
> FLTK or the underlying libraries) has noted this problem and decided to
> recover by
> terminating your program with extreme prejudice. This is not an unreasonable
> strategy for this type of error.
>
It looks like that, because it wasn't by lack of windows.(since I overwrote
FL_HIDE and FL_CLOSE).
So I will probably go for a 2 Hz key generator and see if it works. The strange
think is that the software doesn't look slow at all in this situation. Maybe is
just a queue size the problem...
> > In my mainscreen I overwrote the handle to not do anything with FL_CLOSE or
> > FL_HIDE and it goes there, but even with the return 1;(in FL_CLOSE and
> > FL_HIDE) it returns from Fl::run(). Is there another way to return from
> > Fl::run()? I'm pressuming FL queue reached a maximum size or something like
> > that...
>
> In most programs, Fl::run() won't return. It continues until no windows are
> shown or until some unrecoverable error occurs. Note that you may actually be
> lucky. FLTK is quite ill behaved when faced with memory starvation and may not
> exit in such an orderly fashion. Of course in most common environments, your
> application will become completely unusable long before you see this bug.
>
> > Another interesting fact, is that using Fl_Box(or even Fl_Label or
> > Fl_Button)
> > to draw label could be slow(at least in my software). I will explain better.
> > If I use a buffer outside the Fl_Box/Fl_Label and when I change this buffer
> > I
> > just call (Fl_Box object)->redraw(), it's ok, it's fast.
>
> That's because ...->redraw() doesn't do much. It simply adds the area of the
> subject widget to the area marked as "stale" and schedules it for refreshing
> at
> some time in the relatively distant future. No pixels are immediately harmed.
>
> > But if every time the buffer gets changed I call (Fl_Box)->label((new string
> > array)); it gets slow. And in my software this is done in cycles(every
> > 1/2sec), so it's making difference. Does anyone have a clue what could be or
> > if I'm not using in the intended way? I could subclass Fl_Label to solve
> > this
> > problem, but I want to understand what is really happening.>
>
> I think the widget's label is intended to be like a tattoo: a more or less
> permanent adornment for the widget that describes its purpose. In support of
> this most-common use, changing the label may *force* an immediate refresh. If
> the
> label is outside its subject widget, the parent is refreshed as well. In
> light of
> your 50 char/sec input, it is not surprising that the response is relatively
> slow.
You are right, I was looking at the code. And the method redraw_label() doesn't
simple mark to redraw... it may redraw the owner.. which could be very
expensive...
void Fl_Widget::redraw_label() {
if (window()) {
if (box() == FL_NO_BOX) {
// Widgets with the FL_NO_BOX boxtype need a parent to
// redraw, since it is responsible for redrawing the
// background...
int X = x() > 0 ? x() - 1 : 0;
int Y = y() > 0 ? y() - 1 : 0;
window()->damage(FL_DAMAGE_ALL, X, Y, w() + 2, h() + 2);
}
if (align() && !(align() & FL_ALIGN_INSIDE) && window()->shown()) {
// If the label is not inside the widget, compute the location of
// the label and redraw the window within that bounding box...
int W = 0, H = 0;
label_.measure(W, H);
W += 5; // Add a little to the size of the label to cover overflow
H += 5;
if (align() & FL_ALIGN_BOTTOM) {
window()->damage(FL_DAMAGE_EXPOSE, x(), y() + h(), w(), H);
} else if (align() & FL_ALIGN_TOP) {
window()->damage(FL_DAMAGE_EXPOSE, x(), y() - H, w(), H);
} else if (align() & FL_ALIGN_LEFT) {
window()->damage(FL_DAMAGE_EXPOSE, x() - W, y(), W, h());
} else if (align() & FL_ALIGN_RIGHT) {
window()->damage(FL_DAMAGE_EXPOSE, x() + w(), y(), W, h());
} else {
window()->damage(FL_DAMAGE_ALL);
}
} else {
// The label is inside the widget, so just redraw the widget itself...
damage(FL_DAMAGE_ALL);
}
}
}
>
> Rest assured that all GUI toolkits have similar quirks. Because FLTK is much
> smaller
> it has substantially fewer.
>
> Jim Wilson
Thank you very much... that was helpful.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
