• Post Reply Bookmark Topic Watch Topic
  • New Topic

Designing thread safe user interface  RSS feed

 
Pierre Descamps
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,

I am new here, but I already used this forum many times to get solutions to my troubles. Here I have a general question.

I would like to design a user interface for the control of a microscope (which typically have a lot of hardware component we can interact with). This interface would be implemented in an open-source software written in Java. This software allows the interaction with the hardware through a certain class.

This user interface has several goals:
- Allowing the user to trigger some movements of the hardware (JButton and JToggleButton for stages or lasers, JSlider to set frequency of displacement of lenses or laser pulses, JCombobox to select components...etc...)
- Enabling monitoring of variables (JFreeChart for plotting for instance live position of a stage or intensity detection for a photo-receptor, starting and stoping Threads for the monitoring)
- Feedback algorithm for one important variable (laser pulsing period)

Therefore, some swing elements are subjected to a lot of updating if the user activate the corresponding processes (for instance monitoring of the position of the microscope objective and the corresponding graph). This comes down to 3-4 graphics being updated at most. A very important process for us is the feedback algorithm which performs a fast analysis on the last acquired images (also available from the software interface), modify a variable in the software and a JSlider which indicates to the user the evolution of the variable (period of a laser pulse).

A previous version was written by a former member of our lab, but is not satisfactory. I would therefore like to rewrite entirely the code, but I am not sure of what is the good coding practice in such cases. Here is some point I am thinking of:

- Each interactive process written as a SwingWorker
- Or one class (maybe SwingWorker) with a list of <Component, Process> which would update all the interacting elements according to flags (e.g. boolean updateElement) to centralize every process
- Widgets instead of panels for the interacting elements

Could you comment on the previous points? Any ideas of what I should look into? Or what would be a good way of organizing threads with respect to the swing elements.

I am used to java but not so proficient, I easily missed in the past Java classes that would do exactly what I wanted...

Thanks a lot!!
 
Campbell Ritchie
Sheriff
Posts: 53779
128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

It has never been possible to write a GUI framework which is thread‑safe and which moves faster than an arthritic snail. People have tried and failed. So it is best to assume that Swing components are not thread‑safe. You should consider the likely use‑cases. Are you going to have several people controlling the same microscope simultaneously? How fast do data have to go to the microscope and how fast back? How frequent are the laser pulses and how much information comes back. So consider whether this can all be done in one thread before you try multi‑threading.

If you do need threading, you should have an interface between the computer and the microscope which works without a GUI. Then you write the GUI as an extension to the program.
 
Pierre Descamps
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see. I should have guessed that there is no definitive recipe.

Only one person is controlling the microscope at a time.

It does not have to be incredibly fast, the laser pulse range from us to ms, but the job is done by a micro-controller. When the user change the pulse, then a second-scale transfer of the new value to the hardware is still acceptable. The limitations anyway lie in the software itself, therefore my plugin has to be economic in the sense that it should not disturb the software processes (like image acquisition).

I'll take the last advice because this is a major flaw in what is currently used.

If I try to have a single-threaded process, would a SwingWorker with a list of <Components,Process> calling an updateComponent(Process.getValue()) be something elegant?
(I believe most of the processes can be describe in the simple form of an update of the component according to the output of a process)

Thanks for your answer ;)
 
Campbell Ritchie
Sheriff
Posts: 53779
128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know. But consider the speeds of different processes: to calculate a different laser pulse rate in the computer: maybe 0.1μs. To change an objective, refocus, and alter the condenser diaphragm to match the NA of the new objective: maybe 2s. I suspect the computing part of the process will be much faster than the other parts. If you are capturing images or scans, however, it may be useful to have a thread to pass the data while they are being captured. That could be an ordinary thread, or a worker thread set up via SwingWorker or similar, and you can have a daemon thread to report the progress of the scan in terms or proportion completed.

Doubtless somebody else will have a different idea. As you noticed, there are often several different ways to do the same thing in computing.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!