Thanks everyone for their help with this.
I finally figured out what was going on.
I wrote my example to call invalidatePaint from the correct thread
(the EDT) for one node and the incorrect thread for the other node. I
expected one node to update and the other not to update, however
neither
I agree, my interpretation is that calling invalidatePaint should
result in a repaint sometime soon after.
This differs from Piccolos current (wrong?) behaviour whereby calling
invalidatePaint does not result in a repaint (unless some other event
triggers the repaint).
My gut feel is that
Right. This is the default behaviour for repaint() on a Node. it will group
all the repaint requests together that occur within a UI Cycle.
2009/11/3 Nigel nigel.tamp...@f2s.com
I agree, my interpretation is that calling invalidatePaint should
result in a repaint sometime soon after.
This
Great :) No need to change anything.
2009/11/3 nls...@googlemail.com
The problem seems to be caused by updating the scene graph by a thread
other than the Swing event dispatch thread. This is not allowed, a
solution is explained in the Piccolo2D Patterns.
A consequence of updates by wrong
Good eye, invalidate paint just flags the node as needing to be
repainted. This gets picked up on the next ui cycle. I don't believe
that it will automatically bubble up the stack, though i will need to
re-read the code to confirm this. I will examine your code when i get
home to see if i can
It would seem that indeed, this behavior is intended, though I can't see
why?
invalidatePaint() is used to flag nodes as needing a repaint, but the method
that is primarily responsible for making use of that flag is
validateFullPaint() which is only gets called from PRoot.processInputs().
It
I think this is supposed to be analogous to the AWT
Component.invalidate() method
http://java.sun.com/javase/6/docs/api/java/awt/Container.html#invalidate%28%29
A client might call invalidatePaint() a lot of times before an actual
repaint happens.
michael
Allain Lalonde wrote:
It would
