Re: XForms: redrawing and freezing

Paul Barton-Davis (pbd@Op.Net)
Mon, 20 Jul 1998 15:56:44 -0300

# To subscribers of the xforms list from Paul Barton-Davis <pbd@Op.Net> :

[ 300 objects ]

>That's rather a lot, isn't it?

There are 256 internal software objects, each represented with 2
buttons. Each set of 16 of these pairs of buttons comes with another
16-20 objects.

The program is a real-time "analogue" MIDI sequencer. Its *meant* to
have a lot of buttons :) It has blinking lights too :)

>you could use a TabbedFolder object to both simplify the display and
>to ease the burden on XForms and X wrt object handling.

I don't think this will work for this application, but while you're
here: where are the docs on TabbedFolders ? There's nothing in the
copy of the manual I found online, and fdesign doesn't seem to do much
with them either.

>> doing. This is a very asynchronous program (its gets SIGALRM every
>> 1/100th second).
>
>Are you making XForms calls from within your SIGALRM handler? If so,
>this will cause all sorts of badness, including inexplicable crashes,
>etc.

See my relatively recent message to this list on signals and stuff.

>If you need to make updates of the form in response to the SIGALRM,
>should use the fl_add_signal_callback() interface to register a
>callback handler.

To briefly recapitulate: fl_add_signal_callback() is not quite right
for this situation when used alone, because the timing part of the
non-UI part of things is tighter than XForms allows for. However, I
got all the kinks in the signal handling worked out, and its
great. SIGALRM is delivered by the OS to a signal(2)-installed
handler. Its reliable (enough) and causes the non-UI part of the code
to do its stuff. fl_signal_caught() is used to tell the UI part of the
code to get busy, and this happens soon enough for everything to work
OK. The timing is only critical for the non-UI part, and even there,
only to within audible limits, and on a lightly loaded, non-swapping
486/66, it works beautifully. I have been very impressed by this part
of XForms. Its taken a little while to get the code clean enough that
there are no race conditions between the UI code and the non-UI code,
but it wasn't hard to do.

But to get to the gist of it:

>Other than that, I'm not sure there's a way around your problem.

This seems unfortunate. What is it about freeze/unfreeze that causes a
redraw of the entire form when no such redraw occurs when they are not
used ? Is there some attempt at a heuristic along the lines of:

if (%-age of objects altered > X-percent) {
redraw_form ();
} else {
foreach (object altered) {
redraw_object ();
}
}

As I said, without the freeze/unfreeze, it works but its a little
slow, and because some objects get modified twice, its inefficient
since they get two redraws. What I would like is for freeze/unfreeze
to do nothing more than prevent any redraw until the unfreeze, but
then do just the (non-redundant) redraws that would have occured
without them. They seem to do more than that.

--p
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/