Because we are manually setting the clip, our moveSquare method invokes the repaint method not once, but twice. The first invocation tells Swing to repaint the area of the component where the square previously was (the inherited behavior uses the UI Delegate to fill that area with the current background color.) The second invocation paints the area of the component where the square currently is
i guess my question is, what is it, exactly, that that first repaint is doing?
tell AWT which two specific areas of the screen have changed and need to be redrawn, ie the area where the square was and the area where the square is.
Rob Camick wrote:
tell AWT which two specific areas of the screen have changed and need to be redrawn, ie the area where the square was and the area where the square is.
No that is not accurate.
It does not track the specific areas that need to be withdrawn.
It tracks the smallest rectangular area that contains the two areas to be drawn and then repaints that area in one paint request.
Reread my answer and look at the calculation for this area to be redrawn.
AWT which two specific areas of the screen have changed and need to be redrawn,
Rob Camick wrote:
AWT which two specific areas of the screen have changed and need to be redrawn,
It does NOT redraw two specific areas of the screen.
It only redraws one larger area of the screen.
If you have the original square at (0, 0) and click at (100, 100), then it will redraw an Rectangle on (0, 0, 120, 120). So redraws a large rectangle, not the specific areas.
So if the areas are close to one another only a small area is painted. If the areas are far apart then a large area is repainted.
the two calls to repaint() that occur within moveSquare() tell AWT which two specific areas of the screen have changed and need to be redrawn
i still do think that the order of repaint, then move the squares, then repaint is a bit strange,
Steffe Wilson wrote:the two calls to repaint() that occur within moveSquare() tell AWT which two specific areas of the screen have changed and need to be redrawn
Rob Camick wrote:The wording is not careful, it implies each specific area is redrawn separately.
I don't see how Mr. Wilson's statement implies that the two specific regions will be redrawn separately.
The repaint manager can handle this information any way it likes.
Rob Camick wrote:
You need to understand that the repaint() method just forwards a request to the RepaintManager. In turn the RepaintManager will consolidate the two requests into one. If the repaint manager treats each request separately, then the code will NOT work.
Why wouldn't it work? It seems to me it should work fine
Rob Camick wrote:
So to simulate this I suggested you try using paintImmediately() and you will see the painting behaviour doesn't work as expected. That is the original square is not removed.
This is not because of any limitation/flaw of paintImmediately() or of the repaint manager, but is simply because of how moveSquare()'s implementation is structured.
It doesn't make sense to call paintImmediately() here. Please call repaint() instead, which allows the repaint manager optimize things for you,
Rob Camick wrote:
This code will ONLY work because the RepaintManager consolidates the two requests into one.
The consolidation issue is a red herring that does not help in understanding what SwingPaintDemo3 is doing.
Rob Camick wrote:
I wanted to remove any doubt that two paint requests will ever be made [...]
Obviously with a different implementation of the RepaintManager or listener code or painting code anything is possible. But this question is about the tutorial code, not some hypothetical code.
Rob Camick wrote:
The consolidation issue is a red herring that does not help in understanding what SwingPaintDemo3 is doing.
Well I think it is relevant.
Many people think painting is done as soon is you invoke the repaint() request. How many times have you ever seen a question asking why the painting is not done until after a loop is finished?
Introducing the concept that the RepaintManager consolidates multiple requests in to one and therefore only repaints the final state (not intermediates states) of a component is important to understand.
It helps explain why the painting works even though the state of the component is changed between the two repaint calls.
This message was edited 3 times.
But I stand by my comment that consolidation is irrelevant,
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|