Faster ginput(1)

[Stephen McNeill]

I have a simple GUI which in one particular part does something like the following in an axis with an image:

flag = 1;
while flag,
[x,y,but] = ginput(1);
flag = do_something(x,y,but);
end

Everything is working fine, but the ginput(1) call is very very slow. Using the profiler suggests that the issue is ginput's use of an internal routine wfbp (waitforbuttonpress), which consumes the vast majority of the time (to a level that is unacceptably high for a user).

This seems to have come up a number of times in the newsgroup. Solutions offered include (a) modifying ginput to avoid using uisuspend and uirestore and controlling these calls outside the loop, or (b) using keyboard mouse click handler. Solution (a) doesn't seem to make much difference. Solution (b) ought to be much quicker, although it is more complicated, and there are complications with handling images.

You can see by now that I have tried (a) and want to avoid trying (b). Does anyone have any ideas for an alternative that speeds up ginput(1) ?

Thanks, in advance, for any inspiration.
Stephen

[Steven_Lord]

"Stephen McNeill" <mcne...@remove.this.landcareresearch.co.nz> wrote in
message news:il4aij$40j$1...@fred.mathworks.com...

> I have a simple GUI which in one particular part does something like the
> following in an axis with an image:
>
> flag = 1;
> while flag,
> [x,y,but] = ginput(1);
> flag = do_something(x,y,but);
> end
>
> Everything is working fine, but the ginput(1) call is very very slow.
> Using the profiler suggests that the issue is ginput's use of an internal
> routine wfbp (waitforbuttonpress), which consumes the vast majority of the
> time (to a level that is unacceptably high for a user).

GINPUT is an interactive routine. Its run time will necessarily depend upon
the user's actions.

The time spent in the wfbp subfunction is in fact the amount of time that
GINPUT spent waiting for the user to click on the axes. The ONLY way to
reduce that time is to get quicker users :)

> This seems to have come up a number of times in the newsgroup. Solutions
> offered include (a) modifying ginput to avoid using uisuspend and
> uirestore and controlling these calls outside the loop, or (b) using
> keyboard mouse click handler. Solution (a) doesn't seem to make much
> difference. Solution (b) ought to be much quicker, although it is more
> complicated, and there are complications with handling images.
>
> You can see by now that I have tried (a) and want to avoid trying (b).
> Does anyone have any ideas for an alternative that speeds up ginput(1) ?

See above.

--
Steve Lord
sl...@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

[Stephen McNeill]

"Steven_Lord" <sl...@mathworks.com> wrote in message

> > Everything is working fine, but the ginput(1) call is very very slow.
> > Using the profiler suggests that the issue is ginput's use of an internal
> > routine wfbp (waitforbuttonpress), which consumes the vast majority of the
> > time (to a level that is unacceptably high for a user).
>
> GINPUT is an interactive routine. Its run time will necessarily depend upon
> the user's actions.
>
> The time spent in the wfbp subfunction is in fact the amount of time that
> GINPUT spent waiting for the user to click on the axes. The ONLY way to
> reduce that time is to get quicker users :)

For a simple Matlab script, yes, this is true - I can write a trivial script to use ginput(1) and my finger clicking can't keep up with the speed of the processing in the loop. So far so good...

For my complex UI, it didn't appear to be the case - the response to successive mouse clicks had a very noticeable lag, which was much longer than the rate at which users could click the mouse. With this kind of problem, it's difficult to measure accurate values for how long the lag is, but I would estimate that it is on the order of 0.5-0.7 seconds for the UI that I am currently working on.

After some head scratching, I found the problem... I was issuing a call to:

set(0,'UserData',somestructure);

within the loop containing ginput(1). The "somestructure" had quite a lot of data in it, and this continual saving of the user data took a significant amount of time.

So, a silly bug that I should have noticed earlier...

Stephen