Thanks. I've had a look through and realized that it's a bit more complicated than I first thought. Accessors like BezierCurve.getP1() and getP2() currently return new objects, so it's likely that clients would be relying on that. You can't just change those methods to used cached properties, so you would have to look through the internal usages of these methods and replaced with cached version. That's quite a bit of work.

However, I think this is a fairly important improvement. The performance is perfectly good for typical editor scenarios, but starts to be an issue with very large scene graphs or rapid updates. My use case is a game - I have a background of many very large shapes representing terrain, and then smaller shapes which move through the terrain. One thing I need to do is test visibility, i.e from one of the moving shapes test all of the background shapes within a certain radius to see if they block line of sight. That involves a lot of calls to intersects(), contains() and overlaps(). Currently this is not meeting my performance requirements, and I've tried all the optimizations I can on the client side. I have made extensive use of Java 8 streams - using parallel streams to filter shapes, for example, results in quite significant gains. Would you consider (post Neon) moving to Java 8 as the base execution environment? Many of the testing methods would benefit from the parallel stream short-circuiting operations

In the meantime, I am happy to contribute however I can. I'd be able to create some test scenarios, given that I have a lot of real world data. I can also see if I can implement your suggested caching approach on one or two of the shape classes.