[piccolo2d-dev] [piccolo2d] r885 committed - I totally disagree with a commenting style...
Revision: 885
Author: mr0...@mro.name
Date: Tue Nov 3 03:14:07 2009
Log: I totally disagree with a commenting style
/**
* Returns the width of the line.
*
* @return stroke width
*/
public float getLineWidth()
I prefer to not see my name in such source files.
http://code.google.com/p/piccolo2d/source/detail?r=885
Modified:
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/PFixedWidthStroke.java
===
---
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/PFixedWidthStroke.java
Mon Nov 2 19:25:06 2009
+++
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/PFixedWidthStroke.java
Tue Nov 3 03:14:07 2009
@@ -56,7 +56,6 @@
* @see BasicStroke
* @version 1.0
* @author Jesse Grosjean
- * @author Marcus Rohrmoser
*/
public class PFixedWidthStroke extends PSemanticStroke implements
Serializable {
--~--~-~--~~~---~--~~
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
-~--~~~~--~~--~--~---
[piccolo2d-dev] [piccolo2d] r886 committed - I agree completely. Comments of that kind are pretty useless, but inst...
Revision: 886
Author: allain.lalonde
Date: Tue Nov 3 04:25:39 2009
Log: I agree completely. Comments of that kind are pretty useless, but
instead of just mentioning it, why not fix it?
I disagree with having developer names in files at all. If we didn't have
subversion to track contributions it'd make sense.
http://code.google.com/p/piccolo2d/source/detail?r=886
Modified:
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/PFixedWidthStroke.java
===
---
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/PFixedWidthStroke.java
Tue Nov 3 03:14:07 2009
+++
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/PFixedWidthStroke.java
Tue Nov 3 04:25:39 2009
@@ -154,27 +154,36 @@
}
/**
- * Returns the array used for specifying dash style.
+ * Returns the array representing the lengths of the dash segments.
+ * Alternate entries in the array represent the user space lengths of
the
+ * opaque and transparent segments of the dashes. As the pen moves
along the
+ * outline of the Shape to be stroked, the user space distance that
the pen
+ * travels is accumulated. The distance value is used to index into
the dash
+ * array. The pen is opaque when its current cumulative distance maps
to an
+ * even element of the dash array and transparent otherwise.
*
- * @return array used to specify dash style
+ * @return the dash array
*/
public float[] getDashArray() {
return ((BasicStroke) stroke).getDashArray();
}
/**
- * Returns the dash phase of the current stroke.
+ * Returns the current dash phase. The dash phase is a distance
specified in
+ * user coordinates that represents an offset into the dashing
pattern. In
+ * other words, the dash phase defines the point in the dashing
pattern that
+ * will correspond to the beginning of the stroke.
*
- * @return dash phase of stroke
+ * @return the dash phase as a float value.
*/
public float getDashPhase() {
return ((BasicStroke) stroke).getDashPhase();
}
/**
- * Returns the cap to be used at the end of open segments.
+ * Returns the end cap style.
*
- * @return cap style to use at end of segments
+ * @return the end cap style of this BasicStroke as one of the static
int values that define possible end cap styles.
*/
public int getEndCap() {
return ((BasicStroke) stroke).getEndCap();
@@ -182,18 +191,21 @@
/**
* Returns the line join style.
- * @return the line join style of the codeBasicStroke/code as one
- * of the static codeint/code values that define possible line
- * join styles.
+ *
+ * @return the line join style of the codePFixedWidthStroke/code
as one
+ * of the static codeint/code values that define possible
line
+ * join styles.
*/
public int getLineJoin() {
return ((BasicStroke) stroke).getLineJoin();
}
/**
- * Returns the width of the line.
+ * Returns the line width. Line width is represented in user space,
which is
+ * the default-coordinate space used by Java 2D. See the Graphics2D
class
+ * comments for more information on the user space coordinate system.
*
- * @return stroke width
+ * @return the line width of this BasicStroke.
*/
public float getLineWidth() {
return ((BasicStroke) stroke).getLineWidth();
@@ -202,7 +214,7 @@
/**
* Returns the miter limit of this node.
*
- * @return miter limit of this node
+ * @return the limit of miter joins of the PFixedWidthStroke
*/
public float getMiterLimit() {
return ((BasicStroke) stroke).getMiterLimit();
--~--~-~--~~~---~--~~
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
-~--~~~~--~~--~--~---
[piccolo2d-dev] Re: invalidatePaint does not cause a repaint unless other events are occurring
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's a timer missing somewhere.
It seems the invalidatePaint() message propagates up the node
hierarchy to the PLayer, but is then ignored by the camera, whereas I
think the camera should notice the invalidatePaint and if after a
reasonable time delay (say 1/10th second) should trigger a repaint if
a repaint hasn't already occurred anyway.
This would allow Piccolo to combine multiple paints into fewer paints,
especially effective when large numbers of overlapping nodes all need
to be redrawn at about the same time.
Nigel
On Nov 3, 6:03 am, Michael Heuer heue...@gmail.com wrote:
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#invalid...
A client might call invalidatePaint() a lot of times before an actual
repaint happens.
michael
Allain Lalonde wrote:
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 that calling repaint does the same thing, but is correctly handled
by Swing since it you follow the execution path ultimately, it ends up
callingin 'component.repaint(...);'.
Can someone shed some light on why this is the way it's written?
It would seem to me that a call to repaint() is needed at the end of
invalidatePaint() so that the need for repainting bubbles up to the
underlying Component.
2009/11/2 Allain Lalonde allain.lalo...@gmail.com
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 repelicate your issue.
Thank you for bringing this up.
On 02/11/2009, Nigel nigel.tamp...@f2s.com wrote:
The comment in PNode.java reads
// When you do create you own nodes the only method that you will
// normally need to call is invalidatePaint. This method marks the
// nodes as having invalid paint, the root node's UI cycle will
then
// later discover this damage and report it to the Java repaint
manager.
However, I find that after calling invalidatepaint() the repaint
manager does not discover the damage unless other events are occurring
(such as moving the mouse around).
I was expecting that calling invalidatePaint would result in the node
being repainted some time later - am I doing something wrong or is
Piccolo?
Here is a contrived example (ClockNode.java) - It displays 4 custom
nodes, each showing a clock's second hand. The top 2 clocks are
updated from within the event dispatch thread, the lower 2 clocks are
updated from another thread. The 2 clocks on the left are redrawn via
a call to repaint and the 2 on the right via a call to
invalidatePaint.
if you run it you'll see the clock on the right (calling
invalidatePaint) are only redrawn if you are moving your mouse over
the window.
ClockNode.java
import java.awt.*;
import java.awt.geom.*;
import edu.umd.cs.piccolo.*;
import edu.umd.cs.piccolo.util.*;
import edu.umd.cs.piccolox.PFrame;
public class ClockNode extends PNode {
private GeneralPath secondHand;
private int tseconds; // 10ths of seconds
public void tick() {
tseconds++;
if ( tseconds = 600 ) { tseconds = 0; }
// inform Piccolo that the node needs to be redrawn
if ( useRepaint ) {
repaint();
} else {
invalidatePaint();
}
}
private boolean useRepaint;
public ClockNode(boolean useRepaint) {
this.useRepaint = useRepaint;
// create the needle shape
secondHand = new GeneralPath(GeneralPath.WIND_EVEN_ODD);
secondHand.moveTo(-0.1,0);
secondHand.lineTo(0,1);
secondHand.lineTo(0.1,0);
secondHand.closePath();
}
public void paint(PPaintContext aPaintContext) {
Graphics2D g2 =
(Graphics2D)aPaintContext.getGraphics().create(); //
create - as we mess with the transform
g2.setPaint(Color.BLACK);
//draw the face
g2.draw( new Ellipse2D.Double( getX(), getY(),
[piccolo2d-dev] Re: invalidatePaint does not cause a repaint unless other events are occurring
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 nigel.tamp...@f2s.com
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's a timer missing somewhere.
It seems the invalidatePaint() message propagates up the node
hierarchy to the PLayer, but is then ignored by the camera, whereas I
think the camera should notice the invalidatePaint and if after a
reasonable time delay (say 1/10th second) should trigger a repaint if
a repaint hasn't already occurred anyway.
This would allow Piccolo to combine multiple paints into fewer paints,
especially effective when large numbers of overlapping nodes all need
to be redrawn at about the same time.
Nigel
On Nov 3, 6:03 am, Michael Heuer heue...@gmail.com wrote:
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#invalid...
A client might call invalidatePaint() a lot of times before an actual
repaint happens.
michael
Allain Lalonde wrote:
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 that calling repaint does the same thing, but is correctly
handled
by Swing since it you follow the execution path ultimately, it ends up
callingin 'component.repaint(...);'.
Can someone shed some light on why this is the way it's written?
It would seem to me that a call to repaint() is needed at the end of
invalidatePaint() so that the need for repainting bubbles up to the
underlying Component.
2009/11/2 Allain Lalonde allain.lalo...@gmail.com
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 repelicate your issue.
Thank you for bringing this up.
On 02/11/2009, Nigel nigel.tamp...@f2s.com wrote:
The comment in PNode.java reads
// When you do create you own nodes the only method that you
will
// normally need to call is invalidatePaint. This method marks
the
// nodes as having invalid paint, the root node's UI cycle will
then
// later discover this damage and report it to the Java repaint
manager.
However, I find that after calling invalidatepaint() the repaint
manager does not discover the damage unless other events are
occurring
(such as moving the mouse around).
I was expecting that calling invalidatePaint would result in the
node
being repainted some time later - am I doing something wrong or is
Piccolo?
Here is a contrived example (ClockNode.java) - It displays 4 custom
nodes, each showing a clock's second hand. The top 2 clocks are
updated from within the event dispatch thread, the lower 2 clocks
are
updated from another thread. The 2 clocks on the left are redrawn
via
a call to repaint and the 2 on the right via a call to
invalidatePaint.
if you run it you'll see the clock on the right (calling
invalidatePaint) are only redrawn if you are moving your mouse over
the window.
ClockNode.java
import java.awt.*;
import java.awt.geom.*;
import edu.umd.cs.piccolo.*;
import edu.umd.cs.piccolo.util.*;
import edu.umd.cs.piccolox.PFrame;
public class ClockNode extends PNode {
private GeneralPath secondHand;
private int tseconds; // 10ths of seconds
public void tick() {
tseconds++;
if ( tseconds = 600 ) { tseconds = 0; }
// inform Piccolo that the node needs to be redrawn
if ( useRepaint ) {
repaint();
} else {
invalidatePaint();
}
}
private boolean useRepaint;
public ClockNode(boolean useRepaint) {
this.useRepaint = useRepaint;
// create the needle shape
secondHand = new
GeneralPath(GeneralPath.WIND_EVEN_ODD);
secondHand.moveTo(-0.1,0);
secondHand.lineTo(0,1);
secondHand.lineTo(0.1,0);
secondHand.closePath();
}
public
[piccolo2d-dev] [piccolo2d] r887 committed - adding @since 1.3 tags
Revision: 887
Author: heuermh
Date: Tue Nov 3 10:48:31 2009
Log: adding @since 1.3 tags
http://code.google.com/p/piccolo2d/source/detail?r=887
Modified:
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/nodes/PShadow.java
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/ShadowUtils.java
===
---
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/nodes/PShadow.java
Thu Aug 20 14:06:00 2009
+++
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/nodes/PShadow.java
Tue Nov 3 10:48:31 2009
@@ -37,6 +37,8 @@
/**
* Shadow node.
+ *
+ * @since 1.3
*/
public final class PShadow extends PImage {
===
---
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/ShadowUtils.java
Mon Oct 19 23:13:22 2009
+++
/piccolo2d.java/trunk/extras/src/main/java/edu/umd/cs/piccolox/util/ShadowUtils.java
Tue Nov 3 10:48:31 2009
@@ -39,6 +39,8 @@
/**
* Static utility methods for creating shadows.
+ *
+ * @since 1.3
*/
public final class ShadowUtils {
--~--~-~--~~~---~--~~
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
-~--~~~~--~~--~--~---
[piccolo2d-dev] @since tags in extras, swt
I haven't been able to get clirr to run for the extras or swt modules yet $ clirr.sh --old-version ../piccolo2d.java-release-1.2.1/build/piccolox.jar --new-version extras/target/piccolo2d-extras-1.3-SNAPSHOT.jar --orig-classpath ../piccolo2d.java-release-1.2.1/build/piccolo.jar --new-classpath core/target/piccolo2d-core-1.3-SNAPSHOT.jar --style text $ clirr.sh --old-version ../piccolo2d.java-release-1.2.1/build/piccolox.jar --new-version swt/target/piccolo2d-swt-1.3-SNAPSHOT.jar --orig-classpath ../piccolo2d.java-release-1.2.1/build/piccolo.jar --new-classpath core/target/piccolo2d-core-1.3-SNAPSHOT.jar --style text ... Unable to complete checks:Unable to locate enclosing class edu.umd.cs.piccolox.event.PStyledTextEventHandler$3 for nested class edu.umd.cs.piccolox.event.PStyledTextEventHandler$3$1 so we'll have to add @since 1.3 tags manually to those modules. michael --~--~-~--~~~---~--~~ Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en -~--~~~~--~~--~--~---
[piccolo2d-dev] Re: invalidatePaint does not cause a repaint unless other events are occurring
Great :) No need to change anything.
2009/11/3 nls...@googlemail.com
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 if the right thread invoked the
update). Subsequent invalidatePaints possibly dont reach the root.
Am Dienstag 03 November 2009 02:36:21 schrieb Nigel:
The comment in PNode.java reads
// When you do create you own nodes the only method that you
will // normally need to call is invalidatePaint. This method marks
the // nodes as having invalid paint, the root node's UI cycle will
then
// later discover this damage and report it to the Java repaint
manager.
However, I find that after calling invalidatepaint() the repaint
manager does not discover the damage unless other events are
occurring (such as moving the mouse around).
I was expecting that calling invalidatePaint would result in the
node being repainted some time later - am I doing something wrong
or is Piccolo?
Here is a contrived example (ClockNode.java) - It displays 4 custom
nodes, each showing a clock's second hand. The top 2 clocks are
updated from within the event dispatch thread, the lower 2 clocks
are updated from another thread. The 2 clocks on the left are
redrawn via a call to repaint and the 2 on the right via a call to
invalidatePaint.
if you run it you'll see the clock on the right (calling
invalidatePaint) are only redrawn if you are moving your mouse over
the window.
ClockNode.java
import java.awt.*;
import java.awt.geom.*;
import edu.umd.cs.piccolo.*;
import edu.umd.cs.piccolo.util.*;
import edu.umd.cs.piccolox.PFrame;
public class ClockNode extends PNode {
private GeneralPath secondHand;
private int tseconds; // 10ths of seconds
public void tick() {
tseconds++;
if ( tseconds = 600 ) { tseconds = 0; }
// inform Piccolo that the node needs to be redrawn
if ( useRepaint ) {
repaint();
} else {
invalidatePaint();
}
}
private boolean useRepaint;
public ClockNode(boolean useRepaint) {
this.useRepaint = useRepaint;
// create the needle shape
secondHand = new GeneralPath(GeneralPath.WIND_EVEN_ODD);
secondHand.moveTo(-0.1,0);
secondHand.lineTo(0,1);
secondHand.lineTo(0.1,0);
secondHand.closePath();
}
public void paint(PPaintContext aPaintContext) {
Graphics2D g2 =
(Graphics2D)aPaintContext.getGraphics().create();
// create - as we mess with the transform
g2.setPaint(Color.BLACK);
//draw the face
g2.draw( new Ellipse2D.Double( getX(), getY(), getWidth(),
getHeight () ));
//draw the second hand
g2.translate(getX()+getWidth()/2,getY()+getHeight()/2); //
translate hand so 0,0 is centre of bounds
g2.scale(getWidth()/2,getHeight()/2); // scale the needle
g2.rotate ( Math.toRadians((tseconds*6)/10f+180) );
g2.fill(secondHand);
}
public static void main(String args[]) {
// top left clock - uses repaint
final ClockNode clockNode1 = new ClockNode(true);
clockNode1.setBounds(0,0,200,200);
// top right clock - uses invalidatePaint
final ClockNode clockNode2 = new ClockNode(false);
clockNode2.setBounds(210,0,200,200);
// lower left clock - uses repaint
final ClockNode clockNode3 = new ClockNode(true);
clockNode3.setBounds(0,210,200,200);
// lower right clock - uses invalidatePaint
final ClockNode clockNode4 = new ClockNode(false);
clockNode4.setBounds(210,210,200,200);
PFrame pFrame = new PFrame() {
public void initialize() {
getCanvas().getLayer().addChild(clockNode1);
getCanvas().getLayer().addChild(clockNode2);
getCanvas().getLayer().addChild(clockNode3);
getCanvas().getLayer().addChild(clockNode4);
setSize(500,500);
}
};
// tick clocks 1 and 2 in the event dispatch thread
new javax.swing.Timer(100, new
java.awt.event.ActionListener() {
public void actionPerformed
(java.awt.event.ActionEvent evt) {
[piccolo2d-dev] Re: Issue 131 in piccolo2d: PScrollPane does not use setInteracting() on the canvas
Updates: Status: Verified Comment #3 on issue 131 by heuermh: PScrollPane does not use setInteracting() on the canvas http://code.google.com/p/piccolo2d/issues/detail?id=131 The ScrollingExample looks good to me on several platforms. -- 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 83 in piccolo2d: PSwing are fuzzy when scale!=1, due to buffering of the PSwing
Updates: Status: Verified Comment #24 on issue 83 by heuermh: PSwing are fuzzy when scale!=1, due to buffering of the PSwing http://code.google.com/p/piccolo2d/issues/detail?id=83 Looks good to me on Mac OSX 10.5.8 PPC $ java -version java version 1.5.0_20 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_20-b02-315) Java HotSpot(TM) Client VM (build 1.5.0_20-141, mixed mode, sharing) -- 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 -~--~~~~--~~--~--~---
