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
