This is a very thourough answer. I will try to reply ...
On 8/25/05, Jim Graham <[EMAIL PROTECTED]> wrote:
> >> 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/
>
> either direction will work as long as you override both. Our docs show the
> guts in paint() and then update() redirecting to paint() since it reflects
> what would otherwise go on underneath the covers. Typically an animation
> program overrides paint() to start out with to draw a frame, because that
> is where a program should put its paint() code and that is where someone
> reading the code would go first to find the painting code. The override of
> update() is then added to stop the "erase to background color" flickering.
> When you look at it that way, it seems more logical to have the actual
> painting code in the paint() method, but both work as long as you override
> both.
I'm with you and I tried both, same result.
>
> >> 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?
>
> I don't see how the way you've overridden paint/update() can lead to the
> problem in and of itself. It would be an interesting experiment, but I
> wouldn't abandon your architecture to try to fix this.
I started "porting" my Applet to JApplet but it proved horrendously
errorprone (basically had to cut the file in three --- more work to
fix this than starting from scratch) so I am back at the
AWT/paint/update stage again.
>
> >> 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?)
>
> This is a hard call. While I still need to think about the ramifications
> of what you've done with sending ActionEvents to yourself, simply using a
> Timer instead of rolling your own Thread would not change anything here if
> the action of the Timer was to send the ActionEvent.
I've tried both, same result. A potential error with my previous
"virtual-click-a-button" method was that it used the postEvent from a
custom thread. Given that the documents state that all AWT/Swing code
should execute using the invokeLater technique, this i not
recommended. Anyway, the Swing Timer didn't work either in my setting.
>
> If you switched to periodic repaint() calls instead of sending an
> ActionEvent then it would mean that the calls to update() would happen
> directly instead of as a result of a frame update. You would either have
> to move the frame update code to the update() method, or you would have to
> have two timer events - one to update the frame, and another to call
> repaint - and the two would happen asynchronously.
>
> This points out a potential problem with the way you've written the code
> and could be the root cause of the flood of repaints. Are there ever any
> frames that take longer than 1 second to render? If so, then there is no
> inherent throttling of your ActionEvents to match the extended compute
> time. If, say, you have one frame update that takes 10 seconds to
> complete, then by the time it is done, there will be 10 ActionEvents in the
> queue waiting to be processed. If those events take less time to process
> then you will run through all 10 of them at once and see 10 updates very
> quickly in a row which could look like what is happening to you. If it is
> much more likely to encounter frame updates that take longer than 1 second
> then the backup will be constantly increasing.
Simple answer: no. My updateBackbuffer code paints at most 64 tile
images sized 32x32 each, and actually even when the
non-stopping-updates is going on, there is no performance problem more
than the CPU getting up to like 10% (I'm sorry stated 90% earlier post
but that was a misreading must have been something else..). The way I
know there is mad-updating is via the console output (println) and
flickering (the headsup display widgets are flickering).
>
> Instead of sending an ActionEvent every second which forces a frame update,
> you might want to have some way of creating back-pressure. Either:
>
> - have something in your frame update code which requests the subsequent
> frame when it is done and don't send another ActionEvent until it is
> requested - that guarantees a delay of N milliseconds "between" frames so
> if frames take longer than your delay, the ActionEvents don't accumulate.
> This is kind of hard to implement, though.
>
> - have your frame update code check the last time a frame was updated and
> if it was less than 1 second ago, skip this ActionEvent to catch up
> (another will come along in less than a second).
>
> - you can also look at the time-stamp of the ActionEvent and if it was sent
> more than 1 second ago, skip it in favor of one that you know will be
> coming along very soon.
>
> - have your frame update code increment "number of frames handled" and have
> the event sending code increment "number of frames requested" and if the
> requested count is too far ahead of the handled count (like more than 1
> greater), skip a beat by not sending the ActionEvent this time.
>
> - use calls to update to trigger your frame updates and use "timed repaint"
> events which coalesce:
>
> Timer thread {
> loop {
> sleep(1000);
> repaint(10); // Will coalesce with other repaint(ms)
> calls
> }
> }
>
> update(Graphics g) {
> updateframe();
> paint(g);
> }
>
> paint(Graphics g) {
> g.drawImage(backbuffer);
> drawheadsup(g);
> }
>
> Note that calls to repaint() with no delay will be queued and result in
> calls to update() on a 1 for 1 basis so you could end up with the same
> backlog, but calls to repaint() with a delay (as above) will be coalesced
> with each other.
>
> >> - 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.
>
> That will help keep the frame update code from getting too far behind the
> event sending thread...
>
> ...jim
>
>
Thanks for your time,
/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".
