Gamelab: Update p5.play to 1.1.9-cdo

[islemaster]

Updates p5.play from v1.1.6-cdo to v1.1.9-cdo, with the general result of improving collisions and performance. Here's the complete diff. The main improvements are:

• Adds a broad-phase tunneling check using swept collider bounds for more accurate tunneling prevention, implemented by @joshlory.
• Fixes a nasty bug in CollisionShape.prototype.getBoundingBox that was hurting performance.
• Disables adding colliders to the quadtree - we're disabling the quadtree in Game Lab anyway, but p5.play was still doing the fairly expensive work of adding each collider to the quadtree as it was created.

[Hamms]

Do we have any numbers for how much this update will improve performance?

[islemaster]

I've only got rough measurements but here's what I found:

Using the 500-sprite test program listed in code-dot-org/p5.play#24 I found the run-button-click delay (running student setup code and the first draw loop) improved from about 1.5s to about 0.5s.

• The getBoundingBox method we fix here is only used by the quadtree.
• We didn't see much framerate improvement because we already disabled the quadtree update in Game Lab.
• Even with quadtree disabled, we were adding colliders to the quadtree when they were created which also hit getBoundingBox - hence the big slowdown on the first frame when all 500 sprites get default colliders created. We disable this too so the getBoundingBox code isn't actually called from Game Lab at all anymore.
• I tried re-enabling the quadtree now that getBoundingBox is fixed - it's a lot better, but it's still a bit slower than running without the quadtree. I suspect at this point quadtree might improve performance for apps using groups and having very high collision event density, but we suspect that's the less common case and we'll want to speed up our bounding box code more before we re-enable it.

It looks like the next perf target for Game Lab might actually be lots of small tuning of vector operations - we create and destroy too many vectors in our collision code, cleaning up individual methods and using a vector pool might help.