Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!transit3.readnews.com!news-out.news.tds.net!newsreading01.news.tds.net!86597e80!not-for-mail From: "Philipp" Subject: Re: Update GUI while JSli Message-ID: <1181592862_2387@sicinfo3.epfl.ch> X-Comment-To: comp.lang.java.gui Newsgroups: comp.lang.java.gui In-Reply-To: References: Content-Type: text/plain; charset=IBM437 Content-Transfer-Encoding: 8bit X-Gateway: time.synchro.net [Synchronet 3.15a-Win32 NewsLink 1.92] Lines: 47 Date: Wed, 27 Apr 2011 15:35:25 GMT NNTP-Posting-Host: 96.60.20.240 X-Complaints-To: news@tds.net X-Trace: newsreading01.news.tds.net 1303918525 96.60.20.240 (Wed, 27 Apr 2011 10:35:25 CDT) NNTP-Posting-Date: Wed, 27 Apr 2011 10:35:25 CDT Organization: TDS.net Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.gui:1801 To: comp.lang.java.gui Chris Smith a ocrit : > Philipp 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