Update GUI while JSlider is moving : Java

Knute Johnson a écrit :
>> I want to program a feature where the user moves a JSlider which
>> after some calculations shows a result in the GUI depending on the
>> slider's position. It works now fully in the EDT but lags a lot.
>>
>> This is because the slider creates continously events and each event
>> must be calculated and shown.
>>
>> What would be the optimal architecture for such a construct. How can
>> I drop the processing of events if the GUI lags more than a certain
>> time behind the slider position.

> You need to take a look at JSlider.getValueIsAdjusting(). With this
> method you can test in your ChangeListener whether the slider is
> moving. If it is, don't bother to update your GUI until it stops. Or
> make occaisional updates while it is moving.

I want to update my GUI only when the slider is moving. So your second
solution, ie. making occasional updates seems adapted.

How could I implement that? Maybe I can just compare the present time to
the last repaint time and if the differenc is above a value (say 0.1s),
call a repaint. Is this good design (especially with this hard coded
value of 0.1 s)?

Phil
PS: Sorry to JT for hijacking his thread...

Philipp wrote:
>Knute Johnson a écrit :
...
> > You need to take a look at JSlider.getValueIsAdjusting().
...
>How could I implement that?

<sscce>
import javax.swing.*;
import javax.swing.event.*;

public class SliderValue
extends JPanel
implements ChangeListener {

JSlider slider;
JLabel message;

SliderValue() {
super(new java.awt.GridLayout(0,1));
slider = new JSlider(1,100);
slider.addChangeListener( this );

message = new JLabel( "50" );

add(slider);
add(message);
}

/** The ChangeEvents will be continuously dumped
to the JLabel, but we only want the pop-up
(animation speed, ..whatever) to be updated/appear
once the user has *released* the slider. */
public void stateChanged(ChangeEvent ce) {
message.setText( "" + slider.getValue() );
if ( !slider.getValueIsAdjusting() ) {
JOptionPane.showMessageDialog(null,
"Value selected: " + slider.getValue() );
}
}

public static void main(String[] args) {
SliderValue sv = new SliderValue();
JOptionPane.showMessageDialog( null, sv );
}
}
</sscce>

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-gui/200706/1

Philipp wrote:
...
>I want to update my GUI only when the slider is moving.

Huhh? I read that as *not* moving for some (bizarre)
reason. My bad.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-gui/200706/1

Philipp <sicsicsic@freesurf.ch> wrote:
> Knute Johnson a écrit :
> > You need to take a look at JSlider.getValueIsAdjusting(). With this
> > method you can test in your ChangeListener whether the slider is
> > moving. If it is, don't bother to update your GUI until it stops. Or
> > make occaisional updates while it is moving.
>
> I want to update my GUI only when the slider is moving. So your second
> solution, ie. making occasional updates seems adapted.
>
> How could I implement that? Maybe I can just compare the present time to
> the last repaint time and if the differenc is above a value (say 0.1s),
> call a repaint. Is this good design (especially with this hard coded
> value of 0.1 s)?

Repaint events are coalesced in the event queue automatically by the
event queue implementation, so I think you're doing more work than
necessary. Just call repaint() from the ChangeListener, and repaint in
paintComponent. This will update as often as possible, but no more
often, so the most lag you'll get is the time required to paint once.
The effect described upthread, where the painting falls behind and
catches up in steps, can't occur with repaint events.

A way to mess this up is to do significant calculation in the
ChangeListener in addition to calling repaint() and let those get behind
regardless of painting. If this is a problem, you could try to avoid
the issue by setting flags that arrange for the calculation to be done
in paintComponent instead (of course, storing the result so you don't
repeat the calculation for EVERY repaint).

(If the calculation is TOO expensive, then it should be moved into an
alternate thread; but if that's needed, you have no reasonable hope of
updating your GUI as the slider is moving anyway.)

--
Chris Smith

Chris Smith a écrit :
> Philipp <sicsicsic@freesurf.ch> wrote:
>> Knute Johnson a écrit :
>> > You need to take a look at JSlider.getValueIsAdjusting(). With this
>> > method you can test in your ChangeListener whether the slider is
>> > moving. If it is, don't bother to update your GUI until it stops. Or
>> > make occaisional updates while it is moving.
>>
>> I want to update my GUI only when the slider is moving. So your second
>> solution, ie. making occasional updates seems adapted.
>>
>> How could I implement that? Maybe I can just compare the present time to
>> the last repaint time and if the differenc is above a value (say 0.1s),
>> call a repaint. Is this good design (especially with this hard coded
>> value of 0.1 s)?
>
> Repaint events are coalesced in the event queue automatically by the
> event queue implementation, so I think you're doing more work than
> necessary. Just call repaint() from the ChangeListener, and repaint in
> paintComponent. This will update as often as possible, but no more
> often, so the most lag you'll get is the time required to paint once.
> The effect described upthread, where the painting falls behind and
> catches up in steps, can't occur with repaint events.
>
> A way to mess this up is to do significant calculation in the
> ChangeListener in addition to calling repaint() and let those get behind
> regardless of painting. If this is a problem, you could try to avoid
> the issue by setting flags that arrange for the calculation to be done
> in paintComponent instead (of course, storing the result so you don't
> repeat the calculation for EVERY repaint).
>
> (If the calculation is TOO expensive, then it should be moved into an
> alternate thread; but if that's needed, you have no reasonable hope of
> updating your GUI as the slider is moving anyway.)
>

Thanks for your very complete answer. I think I will end up implementing
your last solution. The one with a different thread. This also because
the repaint method cannot be easily adapted to do the computation.

Philipp