[fxruby-users] FXDataTarget & widget value update delay

Jeroen van der Zijp jeroen at fox-toolkit.org
Tue Oct 3 20:22:42 EDT 2006

On Tuesday 03 October 2006 15:40, Philippe Lang wrote:
> Jeroen van der Zijp wrote:
> > On Tuesday 03 October 2006 10:34, Philippe Lang wrote:
> >> Hi,
> >> 
> >> When assigning a new value to an FXDataTarget
> > programmatically, it takes a certain time for the widget
> > linked to this FXDataTarget to be updated, just as if there
> > was some sort of "polling" inside the framework. Delay can be
> > as long as 1 second sometimes. Why aren't the widgets updated
> > straight away? 
> > 
> > The GUI gets updated when the event loop is about to block
> > for events; as long as there are events [keyboard, mouse,
> > repaints, etc], the event loop processes those with priority.
> > 
> > When all queued-up events have been processed, one would
> > normally go to a blocking state [i.e. yield the CPU in some
> > system call waiting on the event queue].  In FOX we don't
> > yield YET; we instead iterate over the widget tree, and send
> > a SEL_UPDATE to the target of each widget.
> > 
> > Once we've gone through the entire widget tree, THEN we block
> > and yield the CPU.  Of course, each time we update one
> > widget, we check for events again, to ensure that the
> > application reacts instantly when something happens.
> > 
> > The updating process is therefore mostly invisible in the
> > sense that interactive performance is not affected by it:-
> > the only time we do updates is when there's nothing else we would be
> > doing anyway. 
> > 
> > However, this does have a few repercussions on the frequency
> > of updates; in a very busy system with a large number of
> > widgets it may take some time before an entire cycle through the
> > widget tree is completed. 
> > 
> > For this reason, its important to keep the update-handlers
> > small and to avoid unnecessary work in then whenever possible.
> > 
> > The code in getNextEvent() is finely tuned to get great
> > performance, but of course I'm not the one writing the update
> > handlers!  That is up to the software developer himself;  it
> > helps to know what to do and what to avoid.  Hence this mail.
> Hi, thanks for your answer!
> Following your explanation, I finally decided to refresh my widgets manually, when speed is a concern, simply by sending them a SEL_UPDATE message, just after the data target was changed, programatically:
> <widget>.handle(self, FXSEL(SEL_UPDATE, 0), nil)
> Works just fine, widgets get updated instantaneously now.
> But really, I still do not understand why the widget refresh is so slow, and so "random". Sometimes very quick, sometimes near a second. I don't have a Pentium II 166 with 16MB RAM, I can assure you, and the application is not that big for the moment. Maybe it's a "Ruby" effect?

If you want to ensure some sub-tree of the widget tree is fully updated,
you can also use window->forceRefresh() to do this.  No need to add your own
code for it!!

The downside is that forceRefresh() doesn't return until ALL widgets have had
an update.  For a massive application [e.g. CAD system], that may mean ploughing
through thousands of update handlers; the way the normal GUI update is done
is sort of behind the scenes in a piecemeal fashion; its invisible during
normal use because it doesn't impact performance.

At any rate, the API is there and you can use it where you need to....

		- Jeroen

| Copyright (C) 19:10 10/ 3/2006 Jeroen van der Zijp.   All Rights Reserved. |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/fxruby-users/attachments/20061003/c53f9453/attachment.bin 

More information about the fxruby-users mailing list