On 05.01.2013 23:01, Denton Thomas wrote:
>>>>> 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?
No, sorry for being unclear. It's solely to detect that the current
focus_tracker_ variable value is invalid. This would enable you to
see when the current focus widget (inside your group) loses focus
and gets it again. Otherwise you wouldn't scroll the widget back
into the visible area in that case. However, you would only need to
do that, if the user scrolled the focus widget out with the scrollbars
or something like that...
>> 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.
No, sorry again. I thought of events that are delivered to the scroll
widget, but ignored. There can be really *lots* of such events. There
is maybe the most important FL_MOVE, but there are also all events that
other widgets may ignore, like FL_ENTER, FL_LEAVE, drag'n'drop, etc..
The most important events after FL_MOVE would probably be FL_KEYUP and
FL_SHORTCUT. FL_KEYUP is ignored by almost all FLTK widgets, but FLTK
"tries really hard to deliver all events ..." (cited off the top of my
head from the docs elsewhere), so you can be sure that your scroll
widget WILL receive lost of FL_KEYUP events. FL_SHORTCUT will be sent
to (maybe) all widgets if the current focus widget and all parent
widgets ignore an FL_KEYBOARD event. You could say that all key events
are not really a problem, since most users won't type more than about
10 keys per sec., but you can probably see real CPU usage if you move
the mouse pointer fast over your scroll area. Maybe still not very
important, but you can get the idea...
> I figured contains() was the most expensive/unpredictable step, so I
put contains() last.
That seems all okay. contains() moves up the parent() chain of the
widget you requested (i.e. parent(w) if you called contains(w)) until
either it finds the group (in this case the scroll widget) or it finds
the top widget (no parent). This can be a few pointer dereferences,
depending on your overall widget tree depth. Not something I'd be
much concerned about.
> 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!
Something like that, yes. Again, my intention was to detect
focus loss, so that you can act on the focus coming back.
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
