Btw... Commenting out the ComponentListener added in the PSwing constructor does make the problem go away.
Chris On Feb 1, 4:07 pm, "cmal...@pixelzoom.com" <cmal...@pixelzoom.com> wrote: > I've reproduced the problem in an example, see > issue160:http://code.google.com/p/piccolo2d/issues/detail?id=160 > > Chris > > On Feb 1, 2:32 pm, Allain Lalonde <allain.lalo...@gmail.com> wrote: > > > Reason for adding the component listener in PSwing's constructor was that > > during the creation of unit tests for it, a bizarre situation became > > obviously possible. > > > Invisible PSwing node and visible JComponent or Visible PSwing and invisible > > JComponent. > > > Rather than try to parse out the behaviour in those gray areas, I figured > > the best bet would be to make hiding/showing one, hide/show the other. > > > I figured that some optimizations could be done at the JComponent level if > > it were aware that it were invisible (like unloading an image from memory, > > etc). > > > If it's causing more problems than it's fixing I'm 100% for removing it. > > > Try commenting out the ComponentListener registration in the constructor and > > see if the problem goes away. > > > Thoughts? > > > On 1 February 2010 16:24, cmal...@pixelzoom.com > > <cmal...@pixelzoom.com>wrote: > > > > I can't seem to reproduce this in a simple example. But in one of our > > > applications, I see an endless series of calls to the > > > ComponentListener that is added in PSwing's constructor. The calls > > > alternate between componentShown and componentHidden. And there is > > > nothing in the application code that appears to be triggering this, it > > > keeps feeding back through PSwing.setVisible. > > > > So rather than continue to chase my tail on this, I'd like to discuss > > > the motivation for adding this ComponentListener. What purpose is it > > > serving? It seems unnecessary. And undesirable - should client code > > > be able to call setVisible on a Component? And both this > > > ComponentListener and the override of PSwing.setVisibile seem a little > > > dangerous, given how the entire Swing approach works by parenting > > > JComponents to PSwingCanvas.ChildWrapper. > > > > Also note that an additional ComponentListener is added in > > > PSwing.initializeComponent, could this be creating problems, depending > > > on the call order? It seems like there is component initialization > > > going on in the constructor that should really be in > > > initializeComponent. > > > > Thoughts anyone?... > > > > Chris > > > > On Jan 28, 3:46 pm, "cmal...@pixelzoom.com" <cmal...@pixelzoom.com> > > > wrote: > > > > Thanks for being so responsive Allain! > > > > > Unfortunately this change did not correct the problem. And it's > > > > actually unnecessary, since JComponent.setVisible is already a no-op > > > > if the visibility isn't changing. > > > > > To clarify... I'm not seeing a stack overflow, but a continuous > > > > toggling between visible and invisible. And I'm still trying to > > > > reproduce the problem in a simple example. > > > > > Chris > > > > > On Jan 28, 8:05 am, piccol...@googlecode.com wrote:> Revision: 962 > > > > > Author: allain.lalonde > > > > > Date: Thu Jan 28 07:04:37 2010 > > > > > Log: Made PSwing.setVisible lazily call its component's setVisible > > > method > > > > > depending on its current visibility. This should stop the stack > > > overflow > > > > > being experienced by Chris Malley. Since I have been unable to > > > reproduce > > > > > it, I can't test it. > > >http://code.google.com/p/piccolo2d/source/detail?r=962 > > > > > [snip] > > > > -- > > > Piccolo2D Developers Group: > > >http://groups.google.com/group/piccolo2d-dev?hl=en -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
