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 no
Great :) No need to change anything.
2009/11/3
>
> 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 threads is that
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 threads is that PRoot discards the
update and repaint process (it checks
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
>
> I agree, my interpretation is that calling invalidatePaint should
> result in a repaint sometime soon after.
>
> This differs from Picco
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 there'
Maybe, but there's an invalidateLayout that's equivalent then.
Calling repaint doesn't actually force a repaint immediately and may be
called many times between UI cycles. I just marks areas on the canvas as
needing repainting.
2009/11/3 Michael Heuer
>
> I think this is supposed to be analogou
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 s
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 seems
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 repe