Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #1793 > unrolled thread

Update GUI while JSlider

Back to article view | Back to comp.lang.java.gui

Contents

  Update GUI while JSlider "Philipp" <philipp@THRWHITE.remove-dii-this> - 2011-04-27 15:35 +0000
    Re: Update GUI while JSli "Andrew Thompson" <andrew.thompson@THRWHITE.remove-dii-this> - 2011-04-27 15:35 +0000
    Re: Update GUI while JSli "Andrew Thompson" <andrew.thompson@THRWHITE.remove-dii-this> - 2011-04-27 15:35 +0000
    Re: Update GUI while JSli "Chris Smith" <chris.smith@THRWHITE.remove-dii-this> - 2011-04-27 15:35 +0000
      Re: Update GUI while JSli "Philipp" <philipp@THRWHITE.remove-dii-this> - 2011-04-27 15:35 +0000

#1793 — Update GUI while JSlider

  To: comp.lang.java.gui
Knute Johnson a ocrit :
 >> 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...

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#1794 — Re: Update GUI while JSli

  To: comp.lang.java.gui
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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1795 — Re: Update GUI while JSli

  To: comp.lang.java.gui
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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1796 — Re: Update GUI while JSli

  To: comp.lang.java.gui
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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1801 — Re: Update GUI while JSli

  To: comp.lang.java.gui
Chris Smith a ocrit :
> Philipp <sicsicsic@freesurf.ch> wrote:
>> Knute Johnson a ocrit :
>>  > 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

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.gui

csiph-web