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<>
>> Date: Mon, Aug 1, 2011 at 11:10 AM
>> Subject: re: Port Piccolo2D APIs to Android
>> To:
>> Cc:
>> 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:
> 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:
> and the fullPaint() method here:
> 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:
> 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.
> 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 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
> (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 and 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.

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


Piccolo2D Developers Group:

Reply via email to