search

piccolo2d / piccolo2d.java

Structured 2D Graphics Framework
http://piccolo2d.org
Other
51 stars 14 forks source link

Refactor PPath to use Path2D on JDK 1.6+ #152

Closed mro closed 9 years ago

mro commented 9 years ago

Originally reported on Google Code with ID 152

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.

Reported by heuermh on 2009-12-15 20:29:31

mro 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.

Reported by allain.lalonde on 2009-12-15 20:37:18

mro 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.

Reported by heuermh on 2010-04-09 21:26:15

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

Reported by heuermh on 2010-06-23 20:13:04

mro 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?

Reported by mr0738@mro.name on 2010-07-21 10:48:22

mro 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?

Reported by heuermh on 2010-07-21 15:25:43

mro 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.

Reported by samrreid on 2010-07-21 19:21:04

mro 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.

Reported by heuermh on 2010-07-23 15:52:46

mro 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.

Reported by mr0738@mro.name on 2010-07-24 09:16:39

mro 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.

Reported by heuermh on 2010-08-03 20:52:59

mro 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

Reported by heuermh on 2010-08-24 02:22:43

mro 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.

Reported by heuermh on 2010-08-27 16:06:09

mro commented 9 years ago

Reported by heuermh on 2010-08-27 16:06:44

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

Reported by heuermh on 2010-12-22 01:57:16

mro commented 9 years ago

Reported by heuermh on 2013-11-26 20:47:09