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

Reply via email to