Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.gui > #1801
| From | "Philipp" <philipp@THRWHITE.remove-dii-this> |
|---|---|
| Subject | Re: Update GUI while JSli |
| Message-ID | <1181592862_2387@sicinfo3.epfl.ch> (permalink) |
| Newsgroups | comp.lang.java.gui |
| References | <MPG.20d6af3a7a1d1e009898aa@news.altopia.net> |
| Date | 2011-04-27 15:35 +0000 |
| Organization | TDS.net |
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
Back to comp.lang.java.gui | Previous | Next — Previous in thread | Find similar | Unroll thread
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
csiph-web