GoogleCodeArchive / piccolo2d

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

Port Piccolo2D APIs to Android #222

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Port the Piccolo2D APIs, or a relevant subset thereof, to Android.

Original issue reported on code.google.com by heue...@gmail.com on 26 Jul 2011 at 4:16

GoogleCodeExporter commented 9 years ago
Hello, my name is Kenneth Flynn, and I'm the president of Dark Corner Software. 
 We have a set of applications based on Piccolo2D under Java SE that we are 
looking to port to Android.  Rendering maps is a pretty hard problem, but we 
have a nice Piccolo based solution in the SE space; if we have Piccolo under 
Android, we should be able to migrate big chunks of our codebase over.

That said, I've spent about 8-12 hours seeing how this would work and I have 
HelloWorldExample (yeah, the most exciting I know), working under Android, 
including pinch to zoom, sliding, etc.  This is all pretty raw, but with a few 
changes (bounds are specified left, top, right, bottom, instead of x, y, width, 
height; colors are just ints, Matrix instead of AffineTransform, etc.) things 
pretty much work reasonably.

If someone else has started on this and it's just going to be coming, we'll 
probably hold off on going crazy with it, but if no one else has time to work 
on this, we're willing to do so.  I'd be happy to open source the code under 
the same licensing terms.

I can PM someone a test app if desired (watch Hello World grow and shrink 
before your very eyes!).

Original comment by fly...@gmail.com on 31 Jul 2011 at 7:39

GoogleCodeExporter commented 9 years ago
Hello Kenneth, has any further progress been made on this?

Original comment by heue...@gmail.com on 31 Aug 2012 at 4:48

GoogleCodeExporter commented 9 years ago
I made some more progress, but not a tremendous amount.  Our customer in this 
space has dried up, so we've been somewhat focused on other items.  I'm 
interested in this though and might head back to it, particularly if there is a 
desire from the community.  There are a few questions about how it should be 
implemented that might merit further discussion.

Original comment by fly...@gmail.com on 4 Sep 2012 at 4:36

GoogleCodeExporter commented 9 years ago
Possible routes: Use Agile2D to port to OpenGL. As an initial step we can port 
PCanvas and PNode. Alternatively, can we use xamarin (http://xamarin.com/) to 
port C# version on android?

Original comment by tanveer...@gmail.com on 4 Sep 2012 at 4:51

GoogleCodeExporter commented 9 years ago
The C# version of Piccolo2D has not had any contributors since it was moved to 
Google Code in 2008, so I would not recommend using that as a starting point.

My preference would be to refactor the 2.0/svn trunk core in a version 3.0* to 
remove dependencies to Java2D and Swing from the APIs.

Then modular implementations of the core might include Java2D + 
POffscreenCanvas, Java2D + AWT/Swing, SWT, native Processing, Android, JavaFX, 
etc.

It wouldn't be easy, but I think it would be preferable to several parallel 
implementations as we have now.

* or perhaps version 4.0, as 3.0 might just be 2.0 with JDK 1.6 as the minimum 
required JDK.

Original comment by heue...@gmail.com on 4 Sep 2012 at 5:02

GoogleCodeExporter commented 9 years ago
I think the concern is that Agile2D will not run on Android, as it has 
dependencies on java.awt.Color and java.awt.Shape, etc.

Honestly, the effort in porting the core Java code over is not that bad.  The 
real question is whether the ported code is going to perform well on Android.  
The biggest issue is that you must not allocate ANY objects on the paint thread 
under Android if you want any sort of performance.  See:

http://www.pushing-pixels.org/2010/08/02/shifting-gears-from-desktop-to-mobile.h
tml

And Romain Guy has some tweets linked from there as well describing the issue.  
I think it just turns out that Dalvik does not do nearly a good a job of 
allocating/deallocating objects as Hotspot or others.

Combine these changes with the lack of a color object, some variations on 
matrices, etc...  and it starts to look different enough to not be compatible.

If the core APIs were refactored not to have any dependencies on java.awt, 
Java2D, or Swing, as mentioned above, that would dramatically help things, but 
I worry that is a bit of a long term project.  And I think it would be good to 
have a prototype version of the Android code running at least to do that.  One 
concern is the whole 'never allocate on the paint thread' issue does have 
consequences for the overall API.

The code I have does a basic PCanvas and some simple PNodes.  A few of the 
simpler example apps have been ported over.  The challenge is that the 
internals are changing a lot as I move things over to avoid doing things like 
allocating objects on the paint thread.

Original comment by fly...@gmail.com on 4 Sep 2012 at 5:10

GoogleCodeExporter commented 9 years ago
I just posted a draft road map

https://groups.google.com/forum/?hl=en&fromgroups=#!topic/piccolo2d-dev/FUF4lS9T
z_0

which proposes a new 4.0 branch and github mirror to spike on these ideas.  I 
will get started on creating that shortly.

Original comment by heue...@gmail.com on 4 Sep 2012 at 6:31