search

GoogleCodeArchive / piccolo2d

Automatically exported from code.google.com/p/piccolo2d
0 stars 0 forks source link

Refactor PPath to use Path2D on JDK 1.6+ #152

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
PPath currently wraps an instance of java.awt.geom.GeneralPath, which uses
float precision.  JDK 1.6+ provides a java.awt.geom.Path2D class, with
Path2D.Float and Path2D.Double subclasses.

http://java.sun.com/javase/6/docs/api/java/awt/geom/Path2D.html

PPath could be refactored to use Path2D, allowing clients to choose float
or double precision (Path2D.Float or Path2D.Double, respectively).  PPath
should also provide static factory methods that accept double values as
parameters.

Original issue reported on code.google.com by heue...@gmail.com on 15 Dec 2009 at 8:29

GoogleCodeExporter commented 9 years ago 
Of course this is a change that will have to wait quite a few iterations since 
1.5
isn't even supported yet.

Original comment by allain.lalonde on 15 Dec 2009 at 8:37

GoogleCodeExporter commented 9 years ago 
Assigning to myself.

I wonder if we should jump straight to 1.6 for version 2.0.  1.6 is available 
in Sun
and OpenJDK forms on all major platforms except PowerPC Mac OSX.

In the meantime I'll implement this and attach here or possibly create a JDK 1.6
branch off trunk.

Original comment by heue...@gmail.com on 9 Apr 2010 at 9:26

GoogleCodeExporter commented 9 years ago 
Attaching draft implementation for review.  See also issue 153.

Original comment by heue...@gmail.com on 23 Jun 2010 at 8:13

Attachments:

GoogleCodeExporter commented 9 years ago 
I do agree with Chris 
http://groups.google.com/group/piccolo2d-dev/msg/2944bdf8a13ebcfa

Could we do both - add the 1.6 features and still remain 1.5 compilable by 
using reflection and adding a runtime rather than a compile time dependency?

Original comment by mr0...@mro.name on 21 Jul 2010 at 10:48

GoogleCodeExporter commented 9 years ago 
I wonder how that might be possible . . . Path2D is a class added to the JDK in 
1.6.  Perhaps we could create a dependency on that class compiled from an 
OpenJDK class library implementation?

Original comment by heue...@gmail.com on 21 Jul 2010 at 3:25

GoogleCodeExporter commented 9 years ago 
> I wonder how that might be possible . . . Path2D is a class added to the JDK 
in 1.6.

As mentioned in comment 4, this could be done by dynamically checking at 
runtime whether Path2D is available, then instantiating it using reflection if 
so.

Original comment by samrr...@gmail.com on 21 Jul 2010 at 7:21

GoogleCodeExporter commented 9 years ago 
I don't see how that would work, since Path2D needs to be part of the public 
API for the new PPath class.

PPath(Path2D path)
void setPath[Reference](Path2D path)
Path2D getPath[Reference]()
static PPath createPPath(Path2D path)

etc.

In any case, I've created a new branch in svn branches/ppath-refactoring so 
that this work can happen there instead of trunk.

Original comment by heue...@gmail.com on 23 Jul 2010 at 3:52

GoogleCodeExporter commented 9 years ago 
take a Shape input parameter, typecheck internally by RTTI against PPath and 
throw an exception in case.

Not nice, as the type isn't formally part of the public API then, but should 
work.

Even better: cut+paste the PPath interface and add a proxy to PPath if 
available and throw an ex otherwise.

Original comment by mr0...@mro.name on 24 Jul 2010 at 9:16

GoogleCodeExporter commented 9 years ago 
I think there is a nice pattern established by the 1.6 Path2D abstract class 
and concrete Path2D.Float and Path2D.Double classes (similar to rest of JDK 
1.2+ Java2D API) and I've used that in an abstract PPath class and concrete 
PPath.Float and PPath.Double classes.

At this point, I'm not yet convinced that

void setPathTo(...)
void setPath[Reference](Path2D path)
Path2D getPath[Reference]()

methods are necessary.

Then I still have yet to determine whether property change events should be 
thrown from PShape (where they would be "shape" property changes, and clients 
would have to cast to Area or Path2D as appropriate) or from PArea (as "area" 
property changes) and PPath (as "path" property changes) so that the cast would 
not be required.

See r1033 or later on branches/ppath-refactoring.

I'm removing the Milestone-2.0 label since I'm not sure when this might land on 
trunk, with resistance to moving to jdk 1.6+ for version 2.0.

Original comment by heue...@gmail.com on 3 Aug 2010 at 8:52

GoogleCodeExporter commented 9 years ago 
Created a separate issue 190 to track jdk 1.6 changes to core.

In the meantime, I would like to create a separate module on trunk called jdk16 
that will contain the code from the ppath-refactoring branch in a new package

org.piccolo2d.nodes.jdk16

Original comment by heue...@gmail.com on 24 Aug 2010 at 2:22

GoogleCodeExporter commented 9 years ago 
$ svn commit -m "Issue 152, Issue 153 ; merging ppath-refactoring branch to 
trunk, into new modules jdk16 and jdk16-examples" .
...
Transmitting file data ................
Committed revision 1054.

Please review.

Original comment by heue...@gmail.com on 27 Aug 2010 at 4:06

GoogleCodeExporter commented 9 years ago

Original comment by heue...@gmail.com on 27 Aug 2010 at 4:06

GoogleCodeExporter commented 9 years ago 
No news is good news, marking as Fixed.

Original comment by heue...@gmail.com on 22 Dec 2010 at 1:57

GoogleCodeExporter commented 9 years ago

Original comment by heue...@gmail.com on 26 Nov 2013 at 8:47