User interface threads

Question

Ok let's say you're writing a user interface and nothing involves
special-resources like a daqcard so there's no constraints on using things
at once. These are some kind of stupid questions and ideas but I'm really
not sure how to write a quality app with user interface at the moment.
My current design is bad, it is a mainVI which checks the menu and
frontpanel buttons, decides which operation or calculation (if any) is
selected, and sends that to a case structure to perform the operation.
This is sloooow but the most common way in examples that I've seen. The
major problem is that while processing the interface isn't checked and
therefore mouseclicks might be lost. Let's say the processing takes like
500ms on average, that is kind of slow between user-interface querys so it
would feel unresponsive in the mean time.
So here's my three ideas so far, I'd love some comments on what will be FAST
and what would be worthwhile to spend my time on:
1. Leave the app as-is, latch the booleans. However you can't latch
mouse-clicks on a picture indicator that I knew of. I emailed NI before
about this and they just suggested adjusting execution priorities. Anybody
else messed around with this? Probably the worst option, but would take zero
programming.
2. Divorce the user interface and the processing. Create two parallel
while-loops in the same VI, one checks the buttons/menu on the front panel
the other processes the request or calculation. Let's say on average UI
checking takes 1.2ms and processing takes about 500ms. Also in this case is
the watch icon still really my best option (since checking buttons/menu only
takes like 1.5ms on average) for not wasting time repeatedly checking when
there's no input and dividing up cputime accordingly? Seems like there'd be
some overhead in switching back and forth repeatedly.
3. Going all-out and changing to somewhat of an object structure. That way
the UI could create a new "execution" refnum, maintain some list of created
objects, process, return values, destroy any object, so everything could be
going on in parallel. That way one slow calculation won't bog down the rest
of the things the UI requests. The idea is far too abstract to me at this
point, but on a single CPU w98 system is it even worth my thinking about
such a structure? I get the feeling I'd see zero performance change between
the two, in fact maybe worse from any labview thread overhead!
Thanks for any comments. I have seen DAQ intensive apps discussed often, but
don't usually catch much on large user interface apps.
-joey

Answer 1

Hi Joey
First check are you are not recalculating the values on ever iteration of the user interface loop but are you only recalculating
on any change in the user interface values.
Otherwise I would use idea No. 2 but with these changes.
1. Only check the whole user interface every 200-300ms, 1.5ms loop time will unnecessarily load the CPU.
2. Each user interaction could be given a string representation and then placed in a queue to wait for the calculation loop to
have time to process it.(So the user instructions are not lost)
3. Have separate loops for faster and slower calculations (or more) with each having their own queue.
4. The extension to the idea's of having separate loops, is to have each loop in a separate independently running VI (see
VIserver). Still use the queue's to pass the data. This method would allow the calculations and the user interface to run on
separate threads and also lets you alter the execution priority for each VI to fine tune the execution times.
Following these instructions you would produce a basic client-server architecture for your user interface, as long as the UI
doesn't require too many slow calculation results before continuing then this should work well.
If this is still not fast enough then, if you have used suggestion No.4, the calculations can be moved off the users computer to a
faster server (using VIserver) also assuming they are networked.
Hope this gives you some ideas.
Tim S
Joseph Oravec wrote:
> Ok let's say you're writing a user interface and nothing involves
> special-resources like a daqcard so there's no constraints on using things
> at once. These are some kind of stupid questions and ideas but I'm really
> not sure how to write a quality app with user interface at the moment.
>
> My current design is bad, it is a mainVI which checks the menu and
> frontpanel buttons, decides which operation or calculation (if any) is
> selected, and sends that to a case structure to perform the operation.
>
> This is sloooow but the most common way in examples that I've seen. The
> major problem is that while processing the interface isn't checked and
> therefore mouseclicks might be lost. Let's say the processing takes like
> 500ms on average, that is kind of slow between user-interface querys so it
> would feel unresponsive in the mean time.
>
> So here's my three ideas so far, I'd love some comments on what will be FAST
> and what would be worthwhile to spend my time on:
>
> 1. Leave the app as-is, latch the booleans. However you can't latch
> mouse-clicks on a picture indicator that I knew of. I emailed NI before
> about this and they just suggested adjusting execution priorities. Anybody
> else messed around with this? Probably the worst option, but would take zero
> programming.
>
> 2. Divorce the user interface and the processing. Create two parallel
> while-loops in the same VI, one checks the buttons/menu on the front panel
> the other processes the request or calculation. Let's say on average UI
> checking takes 1.2ms and processing takes about 500ms. Also in this case is
> the watch icon still really my best option (since checking buttons/menu only
> takes like 1.5ms on average) for not wasting time repeatedly checking when
> there's no input and dividing up cputime accordingly? Seems like there'd be
> some overhead in switching back and forth repeatedly.
>
> 3. Going all-out and changing to somewhat of an object structure. That way
> the UI could create a new "execution" refnum, maintain some list of created
> objects, process, return values, destroy any object, so everything could be
> going on in parallel. That way one slow calculation won't bog down the rest
> of the things the UI requests. The idea is far too abstract to me at this
> point, but on a single CPU w98 system is it even worth my thinking about
> such a structure? I get the feeling I'd see zero performance change between
> the two, in fact maybe worse from any labview thread overhead!
>
> Thanks for any comments. I have seen DAQ intensive apps discussed often, but
> don't usually catch much on large user interface apps.
>
> -joey