Preview should handle updates itself

[remcoder]

We can remove the necessity for the consumer to call render() after updating public props. This way the lib can decide what type of update is needed.

Outline

Whenever a prop is changed, we queue the change. Every tick, the queue is read and processed and emptied.

Update types

• scene changes can be done immediately w/o requiring the model to be rerendered. Examples:

  • [x] build volume changes
  • [x] clipping planes
  • [ ] ? toggling groups on and off ?

• incremental parsing

  • a new chunk of gcode is parsed and translated into a geometry
  • only the new chunk is added to the scene

• full render of the model

  • the model is removed from the scene
  • the parsed gcode is rendered anew and added to the scene
  • example: extrusion width was changed

[sophiedeziel]

I agree so much with this!

[sophiedeziel]

Some thoughts:

Should we go as far as making the whole render() method private? I don't think so but let's get into that thought experiment.

Not having to call .render() at all is a huge improvement. What would happen if we don't make it private and it's called all over the place? Would we lose some optimization opportunities?

If we're forced to break something or have a subpar experience, maybe we should consider having this as part of the v2->v3 transition. Or plan for v4.

If you ask me, this should be included in the initial v3 release. v3-alpha3 or v3.0. It's the kind of thing that gets me excited. But I'm open to leave that for later.

[remcoder]

We can make it private now and evaluate before we publish. I want to at least update the examples before we publish so that should be a good test.

[remcoder]

Btw where I said 'publish' I meant the final v3.

[remcoder]

Threejs has the option to toggle the update behavior from automatic to explicit. We could adopt the same strategy but I'd prefer to just choose a single approach that always works. Our lib isn't that generic hopefully.

[sophiedeziel]

I'd prefer to just choose a single approach that always works

Me too! There's incredible benefits both for us and for the lib client dev.

There are options that requires a re-render, and some other that don't. The application integrating the lib does not have to know that. The lib knows everything about it's internals and can make that call. I don't see why there would need to be a .render() call externally, even if we have an "explicit" mode. I don't see a use case for an explicit mode, do you?

[remcoder]

see also #282