solids/livecad — pull request #53 by tmpvar (2014-11-03 20:02:16+00:00)
Title: add `._shapeId` to shape generating futures

after the change in `net-oce` to allow js to generate `shapeId`s (solids/net-oce@eb7c660b76461c72c174c4638f3a9512f3ffdd11), the change in `net-oce-protocol` to both add an optional `shape_id` to `NetOCE_Requests` (solids/net-oce-protocol@75a2a7fd53ef992daeae35b6e9712a3ea5c4b3d9) and the change to add the `shapeId` to the request (solids/net-oce-protocol@f4ff4ad30d57af94b0cb86b52668d9bcfc2d5f82) we can now start removing the network round trips as a bottleneck

This commit sets up a `future._shapeId` on all shape generating methods and immediately resolves them with the appropriate `shapeId`. This is then passed to `net-oce-protocol` to be pushed to `net-oce` which will process each request serially.

Example

`display(cube(10).cut(box(5, 10, 100))`

gives us a dependency tree that looks like

```
.- cube(10)
display <- cut <-
' - box(5, 10, 100)
```

which gets processed like

1. ` cube(10)`
2. `box(5, 10, 100)`
3. `cut({id : 1 }, { id: 2 })`

=====

This results in local speeds like:

![screen shot 2014-11-03 at 2 43 04 pm](https://cloud.githubusercontent.com/assets/46673/4889193/bd96a010-6393-11e4-910f-e5a2da061353.png)

vs master which looks like:

![screen shot 2014-11-03 at 2 59 30 pm](https://cloud.githubusercontent.com/assets/46673/4889235/f7ec6344-6393-11e4-8210-9339ce31f73d.png)

We can probably go faster if we simply do not respond to shape creation operations, and by amortizing `display` to stream objects in and have them added to the scene one at a time instead of having to process hundreds at a time.