[piccolo2d-dev] Re: Release Piccolo2D.Java 1.3 failed
An update on where we're at with the PSwing issues... Issue 158 was resolved by Allain last week, and fixed a couple of our problems. Issue 159 was opened a few minutes ago, and is related to PSwing transform/picking problems. I am still investigating one additional issue, where a PSwing Component is receiving an endless series of events that toggle its visibility on and off. As soon as I isolate, I'll create an issue. That summarizes all of the problems we've encountered with 1.3-rc1. Chris On Jan 28, 12:29 pm, Michael Heuer heue...@gmail.com wrote: The following people voted on release 1.3rc1: Michael Heuer +1 Allain Lalonde +1 Chris Malley -1 The vote failed since it did not receive at least three +1 binding votes and no -1 binding votes. New issues related to PSwing were discovered and are being addressed. Another release candidate (1.3rc2) will be created when these issues are closed and validated. On behalf of the Piccolo2D developers, michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Issue 159 in piccolo2d: events not delivered to PSwing Components for some transforms
Comment #2 on issue 159 by allain.lalonde: events not delivered to PSwing Components for some transforms http://code.google.com/p/piccolo2d/issues/detail?id=159 I've narrowed it down to the code in PNode.globalToLocal. It seems to be lossy. I'll try changing it to compute a globalTransform then inverting once. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] [piccolo2d] r963 committed - Fixing error with rounding error bug when calculating inverseTransform...
Revision: 963
Author: allain.lalonde
Date: Mon Feb 1 11:30:02 2010
Log: Fixing error with rounding error bug when calculating inverseTransform
repeatedly during globalToLocal.
Fixes Issue 159
http://code.google.com/p/piccolo2d/source/detail?r=963
Modified:
/piccolo2d.java/trunk/core/src/main/java/edu/umd/cs/piccolo/PNode.java
===
--- /piccolo2d.java/trunk/core/src/main/java/edu/umd/cs/piccolo/PNode.java
Mon Jan 18 16:07:38 2010
+++ /piccolo2d.java/trunk/core/src/main/java/edu/umd/cs/piccolo/PNode.java
Mon Feb 1 11:30:02 2010
@@ -95,3663 +95,3902 @@
* @author Jesse Grosjean
*/
public class PNode implements Cloneable, Serializable, Printable {
-/**
- * The minimum difference in transparency required before the
transparency
- * is allowed to change. Done for efficiency reasons. I doubt very
much that
- * the human eye could tell the difference between 0.01 and 0.02
- * transparency.
- */
-private static final float TRANSPARENCY_RESOLUTION = 0.01f;
-
-/**
- * Allows for future serialization code to understand versioned binary
- * formats.
- */
-private static final long serialVersionUID = 1L;
-
-/**
- * The property name that identifies a change in this node's client
- * propertie (see {...@link #getClientProperty getClientProperty}). In an
- * property change event the new value will be a reference to the map
of
- * client properties but old value will always be null.
- */
-public static final String PROPERTY_CLIENT_PROPERTIES
= clientProperties;
-
-/**
- * The property code that identifies a change in this node's client
- * propertie (see {...@link #getClientProperty getClientProperty}). In an
- * property change event the new value will be a reference to the map
of
- * client properties but old value will always be null.
- */
-public static final int PROPERTY_CODE_CLIENT_PROPERTIES = 1 0;
-
-/**
- * The property name that identifies a change of this node's bounds
(see
- * {...@link #getBounds getBounds}, {...@link #getBoundsReference
- * getBoundsReference}). In any property change event the new value
will be
- * a reference to this node's bounds, but old value will always be
null.
- */
-public static final String PROPERTY_BOUNDS = bounds;
-
-/**
- * The property code that identifies a change of this node's bounds
(see
- * {...@link #getBounds getBounds}, {...@link #getBoundsReference
- * getBoundsReference}). In any property change event the new value
will be
- * a reference to this node's bounds, but old value will always be
null.
- */
-public static final int PROPERTY_CODE_BOUNDS = 1 1;
-
-/**
- * The property name that identifies a change of this node's full
bounds
- * (see {...@link #getFullBounds getFullBounds},
- * {...@link #getFullBoundsReference getFullBoundsReference}). In any
property
- * change event the new value will be a reference to this node's full
bounds
- * cache, but old value will always be null.
- */
-public static final String PROPERTY_FULL_BOUNDS = fullBounds;
-
-/**
- * The property code that identifies a change of this node's full
bounds
- * (see {...@link #getFullBounds getFullBounds},
- * {...@link #getFullBoundsReference getFullBoundsReference}). In any
property
- * change event the new value will be a reference to this node's full
bounds
- * cache, but old value will always be null.
- */
-public static final int PROPERTY_CODE_FULL_BOUNDS = 1 2;
-
-/**
- * The property name that identifies a change of this node's transform
(see
- * {...@link #getTransform getTransform}, {...@link #getTransformReference
- * getTransformReference}). In any property change event the new value
will
- * be a reference to this node's transform, but old value will always
be
- * null.
- */
-public static final String PROPERTY_TRANSFORM = transform;
-
-/**
- * The property code that identifies a change of this node's transform
(see
- * {...@link #getTransform getTransform}, {...@link #getTransformReference
- * getTransformReference}). In any property change event the new value
will
- * be a reference to this node's transform, but old value will always
be
- * null.
- */
-public static final int PROPERTY_CODE_TRANSFORM = 1 3;
-
-/**
- * The property name that identifies a change of this node's
visibility (see
- * {...@link #getVisible getVisible}). Both old value and new value will
be
- * null in any property change event.
- */
-public static final String PROPERTY_VISIBLE = visible;
-
-/**
- * The property code that identifies a change of this node's
visibility (see
- * {...@link #getVisible getVisible}). Both old value and new value will
be
- * null in
[piccolo2d-dev] Re: Issue 159 in piccolo2d: events not delivered to PSwing Components for some transforms
Updates: Status: Fixed Mergedinto: - Comment #3 on issue 159 by allain.lalonde: events not delivered to PSwing Components for some transforms http://code.google.com/p/piccolo2d/issues/detail?id=159 This issue was closed by revision r963. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Issue 159 in piccolo2d: events not delivered to PSwing Components for some transforms
Comment #4 on issue 159 by cmal...@pixelzoom.com: events not delivered to PSwing Components for some transforms http://code.google.com/p/piccolo2d/issues/detail?id=159 This issue appears to be fixed. Caveat: r963 diff shows that most of PNode source file was modified. In a separate email, Allain noted that the fix was in globalToLocal(final Point2D globalPoint) and computeGlobalTransform(final PNode node). So I patched PNode 1.3-rc1 with just those methods, and it tests OK. I did NOT test the entire new version of PNode, trying to keep my test environment as true to rc1 as possible so that I don't pull in new problems. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: Issue 159 in piccolo2d: events not delivered to PSwing Components for some transforms
Updates: Status: Verified Comment #5 on issue 159 by cmal...@pixelzoom.com: events not delivered to PSwing Components for some transforms http://code.google.com/p/piccolo2d/issues/detail?id=159 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
[piccolo2d-dev] Re: r962 committed - Made PSwing.setVisible lazily call its component's setVisible method d...
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
Re: [piccolo2d-dev] Re: r962 committed - Made PSwing.setVisible lazily call its component's setVisible method d...
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.comwrote: 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
