> >>> Albrecht wrote:
> What about adding here:
>
> if (!contains(f_new)) focus_tracker_ = 0; // focus in another group
>
> > if(f_new && (f_new != focus_tracker_) && contains(f_new)) {
> > focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
> > scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
> > redraw();
> > }
> > return ret;
> > }
> >
I guess that's because of cycles, yes?
> So, if you want to save some (or more) CPU cycles, I'd recommend
> checking what is really needed, and then filter events and/or do
> some basic, but simple checks first.
I guess you're thinking it would be cheaper to break up the logical AND
comparisons? I hadn't considered that.
I figured contains() was the most expensive/unpredictable step, so I put
contains() last. If (f_new != focus_tracker_) fails, then the && would fail and
contains() wouldn't run. If contains() is not the most expensive part, then I'm
up the wrong tree.
For my own applications, I also don't specifically need to know whether focus
is outside the group ... finding it is just a byproduct. If your own
application needs the flag, though, how about:
if (f_new && (f_new != focus_tracker_) {
if(contains(focus_tracker_) {
... do the scroll, etc ...
}
else focus_tracker_ = 0;
}
This would avoid running contains() when focus doesn't change, but it ensures a
flag is 0 when focus is outside the group. I think the down side is that
contains() would -always- run when focus is outside the group, even when focus
does not change. I don't need that, but maybe you do!
DLT
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
