Whoa. Things like this scares me: http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html (look at the section under "The event dispatching thread", the red section)
I get the general feeling the AWT/Swing developers have been trying to let the application developers not worry about threads (eg. hiding the AWT-Event thread etc.) but then, when you get to the bottom of things you REALLY have to worry about threads. Quote: "To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread." I guess this applies to generel, old-skool AWT too... Wow. Great. I think I'm gonne build my own GUI toolkit inside my Applet instead of using AWT ... Question is how do I avoid AWT altogether... /Olof On 8/25/05, Olof Bjarnason <[EMAIL PROTECTED]> wrote: > Thanks for you answer Chet. > > On 8/25/05, Chet Haase <[EMAIL PROTECTED]> wrote: > > Olof, > > > > I'm not sure of where the "mad update" is coming from, but you > > don't want to call update() from paint; that's actually backwards > > from what the system expects. > > > > From the Component javadocs: > > The update method of Component calls this component's paint > > method to redraw this component. > > and: > > Subclasses of Component that override this method should > > either call super.update(g), or call paint(g) directly > > from their update method. > > OK, guess I misread the docs. Actually, I followed this tutorial to begin > with: > http://www.dgp.toronto.edu/~mjmcguff/learn/java/ > > > > > Update calls paint() internally, which means that it calls > > your paint, which calls update, which ... > > Yes, if I don't override update(). > > > Of course, you've overridden update(), so this changes the > > behavior, but it's a bit confusing at the least. But there could > > be more wrong here: it could be that by changing the nature of > > update/paint interaction, you're getting in the way of the > > regular system of issuing and consuming repaint() events, which > > could cause the paint calls to keep being issued. > > > > The solution here is to simply override paint() and do your > > painting there. Or if you're using Swing, override paintComponent() > > instead. Don't override update, or at least not in the manner you > > are doing currently. > I'm using AWT I guess, no Swing. I'm trying to go for old-API in order > to make the game runnable on more computers. I compile for 1.4.2, but > I guess 1.4.2 has Swing so I could go for paintComponent, but my > feeling is I should use paint(), eg.the tutorial uses paint(). > Comments? > > > > > To improve performance in general: > > - use a timer to schedule regular repaints so you don't get > > swamped with constant repaint events (similar to what you're > > doing, but I don't follow the complexity of using key actions > > for this. Why not simply issue a repaint call?) > > - only draw the area that's changed. So if only one rectangle > > of the playing area has changed, draw that updated region > > into the back buffer, and copy that region of the back buffer > > into the window. > Thanks for these tips, I will try and implement the > update-only-changed-area thingy. > > Some things I've tried now: > > - I don't override update() (removed it completely from my Applet), > and I put the painting code in paint(). No change. > - I removed ALL repaint() calls from my Applet. Of course the graphics > isn't updating at all to begin with, but then the mad-updating begins > ... No change. > - I changed to JRE 1.5.02. No change. > > Confused... > > /Olof > > > > > Chet. > > > > > > Olof Bjarnason wrote: > > > Hi there! > > > > > > I am new to the list, I hope I found the right list to ask this > > > question, otherwise i appologize and ask for directions of which list > > > is more appropriate. > > > > > > I am developing an Applet based 2d game ( a minimalistic SimCity clone > > > ). In an attempt to decrease flickering I skip the > > > erase-to-background-color default behaviour of paint() by overriding > > > it and putting my drawing code there instead. paint(Graphics g) simply > > > calls update(g), as per recommendation in Java API docs: > > > > > > public void update(Graphics g) { > > > // Background: map field > > > g.drawImage(backbuffer, 0, 0, this); > > > > > > // Foreground: headsup display > > > headsup.draw(g); > > > } > > > > > > public void paint(Graphics g) { > > > update(g); > > > } > > > > > > The headsup-display draws some lines ontop of the background map > > > image, for example the cursor. > > > > > > Now the problem is that even though the window (Firefox or > > > AppletViewer) is left unresized and nothing obscures it, the > > > update-method gets called repeatedly without-end, giving > > > less-than-optimal performance, and a lot of flickering. > > > > > > Even more strangely, when starting the Applet, it works fine (update() > > > gets called once a second..) for a some 5-10 seconds, then the mad > > > update()-calling begins. I'm under WinXP, JRE1.4.2. The continuous > > > update:ing really hogs the CPU (gets up to 90%) which is not good for > > > a game supposed to be run on a web page while the user listens to > > > music for example. > > > > > > Technical details: > > > > > > In order to drive the simulation, I have a background thread which > > > approximately once a second fires an ActionEvent on a phony Button > > > which is a member field of the Applet: > > > > > > private Button triggerStepButton; > > > > > > public void run() { > > > Thread.currentThread().setPriority(1); > > > while (running) { > > > ActionEvent ae = new > > > ActionEvent(this.triggerStepButton, > > > ActionEvent.ACTION_PERFORMED, ""); > > > > > > Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(ae); > > > try { > > > Thread.sleep(1000); > > > } catch (InterruptedException e) { > > > e.printStackTrace(); > > > } > > > } > > > } > > > > > > run() is a method of my Applet, aswell as triggerStepButton. > > > triggerStepButton has one listener: the Applet. In the init() method > > > of the Applet: > > > > > > triggerStepButton = new Button(); > > > triggerStepButton.addActionListener(this); > > > > > > So, the Applet has the following signature: > > > > > > public class TerraformerApplet extends Applet implements Runnable, > > > ActionListener { ... > > > > > > The actionPerformed method of the Applet looks like this: > > > > > > public void actionPerformed(ActionEvent e) { > > > model.step(); > > > updateBackbuffer(); > > > repaint(); > > > } > > > > > > ... where model contains the SimCity model and it's specific rules. > > > updateBackbuffer updates the parts of the background image (called > > > backbuffer) which have changed since last call. The actionPerformed > > > method is called once a second, even after the mad update:ing has > > > begun. > > > > > > Why not call model.step() and updateBackbuffer() in run()? Well I want > > > to avoid the synchronization hassle needed to make only one thread > > > access the model/background image at-a-time. This solution is simpler, > > > even though it might seem slightly complicated at a first glance. I > > > tried the synchronization solution first, but then I remembered that > > > the whole event-queue system is built around the idea of running ONE > > > EVENT AT A TIME, so it seemed natural to squeeze in the > > > step()-triggering into it. I assume the postEvent-method is > > > synchronized? > > > > > > So, does anyone have any idea what is going on? Somehow I get the > > > feeling the repaint() queries are not "eaten up" in the event queue, > > > as if there is supposed to be some way to do a consume(e), analogous > > > to KeyEvent's, but the API docs gives no hint of this. Or, I got an > > > infinite loop calling repaint() somewhere, which is triggered after a > > > few seconds of the Applet running. Both seem far-fetched at the > > > moment... > > > > > > Thanks for any answers, > > > > > > /Olof > > > > > > =========================================================================== > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > > > of the message "signoff JAVA2D-INTEREST". For general help, send email to > > > [EMAIL PROTECTED] and include in the body of the message "help". > > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
