Kenneth Flynn wrote: > Michael, > > Responses inline. BTW, this is my main email; the gmail one is just from > the google code tracker. > > I've attached my latest test app as an apk. This requires a phone with > 2.3.3/4 right now. If you can test this, try out pinch to zoom, panning, > and turning your phone on it's side to see state persist across restarts. > > On 8/1/2011 5:33 PM, Kenneth Flynn wrote: >> >> ---------- Forwarded message ---------- >> From: Michael Heuer<heue...@gmail.com> >> Date: Mon, Aug 1, 2011 at 11:10 AM >> Subject: re: Port Piccolo2D APIs to Android >> To: fly...@gmail.com >> Cc: piccolo2d-dev@googlegroups.com >> >> >> Hello Kenneth, >> >> Great to see your interest in an Android port -- we met at JavaOne a >> few years back. I would like to help where I can. > > Great! I thought we probably had met at your session at JavaOne. Since we > spoke then, Android has become a very important part of our portfolio--our > customers are pressing to move to Android devices, and whether that's a good > idea or not, it's kind of starting to feel inevitable. The good news is > that as a fresh market, we have a real chance to make an impression. The > problem we're really seeing is a lack of tooling, particularly in the UI > space. > > What really surprises me is that no one has put together a scenegraph yet, > particularly including even Google to at least match the JavaFX API > (although no one much seems to care about that). PIccolo seems like the > obvious choice, and we have a lot of experience with it. It's funny that > we're a bit in keeping with some of the original funders of Jazz (we've > actually used it on DARPA projects!). >> >> I can think of a bunch of structural questions right off the bat >> >> On 1.3-branch, trunk (2.0), or both? > > I've started with the 1.3.1 branch, as that was the most recent release. It > might make more sense to work from trunk. I was mainly interested in seeing > how hard it was to do this at all. The answer to that is it seems very > doable. > > I think there is probably a deeper question here, that you're hinting at > next--there are enough things that have to be done differently that the > codebase is going to end up more different than even the swt one. 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.html > > 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. > > Since I posted on the issue tracker, I've gotten the PFixedBounds thing to > work, but to get fixed width lines, I have to add an extra step to the paint > cycle of PNode, and track all the Paints used by subobjects, which tweaks > how you build PNodes. The actual use of the stroke width is all buried down > in native code, and you cannot just override Paint.getStrokeWidth(). For > this and to save object allocations, I'm looking at putting decorators > around Paint (this is about half of a Graphics2D--the concept in Android is > split between a Canvas and a Paint, which is not the same as a Java Paint, > but rather more like the get/setColor, get/setFontSize etc. parts of G2) and > Path (GeneralPath direct equivalent) that forward update calls back to the > PNode that created them. This ends up sort of looking like PBounds but with > hooks back to the object. You can see what I mean here: > > https://www.darkcornersoftware.com/hg/open/piccolo2d/file/64dc4e493174/piccolo2d-android-core/src/main/java/com/darkcorner/piccolo2d/ForwardingPaint.java > > and the fullPaint() method here: > > https://www.darkcornersoftware.com/hg/open/piccolo2d/file/64dc4e493174/piccolo2d-android-core/src/main/java/com/darkcorner/piccolo2d/PNode.java > > Of course, in my actual code production Java SE code, I don't ever use > PFixedWidthStroke, but rather do the "invert the transform" thing to get the > whole object back up to size when rendering links between nodes (which I > also had to cut off on the viewport for performance, which is something we > could talk about going upstream with)... But that's off topic. > > There are enough 'things' like this that the codebase is going to end up > having some large *internal* structural differences. End users will likely > be able to port their code with a minimum of changes--it's just the bits > that make it go under the hood that will be different. > > So I think it's less an issue which version of the existing Piccolo I base > this off of. Given that, I should probably be doing trunk... > >> Will this build as a module in >> the current maven build, > > Yes. Well, probably at least two modules: piccolo-android and > piccolo-android-examples. I'm building with Maven right now, and see no > issues with upstream integration. >> >> or does it need to be its own project? > > The projects won't have any dependency on the core piccolo code. This could > be separate or together as best suits the release process. I'm inclined for > this to be separate, kind of like Piccolo.NET, unfortunately, just because > it will probably be different enough to have it's own release cycle. >> >> What >> should the maven module and package name be? > > I would go with piccolo-android, and org.piccolo2d.* >> >> and on how we might proceed >> >> Do you want to send patches and have a developer commit them? Or >> commit to a git mirror and have a developer apply pull requests back >> to subversion? > > I've set up a mercurial repo on our company server here: > > https://www.darkcornersoftware.com/hg/open/piccolo2d/ > > Please don't take the license headers on this source as meaning anything, > that's just our default to put MPL on everything. I just haven't setup BSD > with the right headers for your code in my IDE yet, as I'm not sure if we > want to put this in a different namespace or not--and I'm mainly trying to > get far enough to know how feasible this is. > > I would be inclined to do fixes there, and do pull requests to get it back > in SVN if that would work. If you're more comfortable with bitbucket, I'd > be okay with that as well. I think either hg or git is probably fine, but > hg is easier for us to set up corporate infrastructure for (I was so glad > when I got rid of doing svn over ssh, I'm just not going back to it!), so > we're using hg as our DVCS of choice. >> >> Or would you like developer access to the Piccolo2D >> project? > > If we go forward with this, I probably should join the mailing lists, etc. > Unless we try to bring the codebases together with some sort of abstraction > layer, I don't see myself needing commit access. Speaking of putting them > together--I think that's a bad idea until we have something much more > working. I think there are a few good ideas with the decorators and stuff > that might feed upstream, but I think that will take a good bit of time. >> >> My motivation is to have Piccolo2D on Android work with Processing on >> Android. That may complicate things a bit. >> >> http://processing.org >> >> http://wiki.processing.org/w/Android >> >> https://github.com/heuermh/piccolo2d-processing > > I'm not familiar enough with Processing to really speak to this. I took a > look at your code and the websites, and I'm trying to wrap my head around > what you're doing. It seems like you're setting Piccolo up as a rendering > target for processing? If that's the desire, then putting them together > will be roughly the same level of complexity as what you're currently doing, > with just some minor API differences (int instead of java.awt.Color). >> >> There are also some things I like about the Android APIs that might be >> nice to back-port functionality-wise to Piccolo2D.java proper, e.g. >> the animation package. > > My hope would be that we can explore some of those things once a basic > platform is in place, and start to bring things together. I think > ultimately, it would be nice to have a single codebase with just a few > pieces different for swt, android, etc. and the core all the same, but doing > that in a performant way is going to be quite challenging. > > For what it's worth, I'm having a lot of fun with this. :) And learning a > lot more about low level Android rendering. :) > > I'd like to correct the license headers and packaging in my existing code. > If you're okay, I'll move things to org.piccolo2d or org.piccolo2d.android > (your choice), and update the licenses. How should I alter the license > headers though? Just add a (c) 2011 DCS for us in the list?
I think package names org.piccolo2d.android and org.piccolo2d.android.examples would be great for piccolo-android and piccolo-android-examples maven modules on trunk (directories android and android-examples). I am still reading up on the copyright stuff though, see e.g. http://webmink.com/essays/on-copyright-aggregation http://live.gnome.org/CopyrightAssignment/Guidelines I will learn hg over the weekend and look forward to taking a look at your repository and running the example(s). What I did with Piccolo2D on Processing is just a hack and only works with the Java2D-based Processing graphics implementation. I see the need for all of AWT/Swing component (PCanvas) Offscreen renderer, for applications driven by a rendering loop (POffscreenCanvas) Alternate *Graphics2D renderers, for vector image export (e.g. SVGGraphics2D) SWT component (PSWTCanvas, remove dependency on Java2D) HTML5/Canvas javascript implementation (piccolo2d-js) Processing implementation (remove dependency on Java2D) Processing.js javascript implementation (is this even possible?) Android (Canvas+Paint) implementation (remove dependency on Java2D) Does that mean a small core library without any dependency on Java2D and then a shim for each of these, or maybe we need to continue along the path of parallel APIs, I don't know. michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
