Remove old recording APIs.

[gw3583]

These are not maintained or used now that we have scene capture
functionality working.

---

This change is 

[gw3583]

In theory, there is still a use case for the old binary recording system - it supports recording a sequence of frames.

In practice, this seems un-maintained (it didn't work when I tested it today), and I don't intend to use it again now that we have scene capture functionality working reliably.

What do you think @kvark @gankro @mrobinson @jrmuizel ?

[gw3583]

If / when this lands, we can close the following:

#2583
#2411
#2231
#2131
#2201
#1253
#1402
#1826

[mrobinson]

@gw3583 I'm okay with this. We briefly discussed a better high level API (like the current YAML one) last week, but I think the consensus was that we should be using serde serialization instead of a custom serializer.

[kvark]

@mrobinson

We briefly discussed a better high level API (like the current YAML one) last week, but I think the consensus was that we should be using serde serialization instead of a custom serializer.

To be fair, the high-level API we discussed is mostly unrelated to the binary recordings. And the binary stuff uses Serde for encoding/decoding (unlike YAML).

@gw3583

In practice, this seems un-maintained (it didn't work when I tested it today), and I don't intend to use it again now that we have scene capture functionality working reliably.

I think a better solution to this problem in the long term would be sequential capturing. Most of the capture time today comes from reading back texture data, and this would be minimal as long as we keep track of what's already on disk and just re-use it. So at the end of the day we'll end up with a sequence of captured frames sharing the resources, and we'll add some controls to wrench to go back and forth between the frames.

So yeah, it does seem like the binary recording can be dropped, even though it's a fairly small chunk of code.

[mrobinson]

To be fair, the high-level API we discussed is mostly unrelated to the binary recordings. And the binary stuff uses Serde for encoding/decoding (unlike YAML).

My comment was just in relation to the bits of this PR that remove the YAML frame writer. I have no reservations at all about removing the binary bits.

[kvark]

... even though it's a fairly small chunk of code.

...

+1 −2,470

😨

[jrmuizel]

The big advantage of being able to record to yaml is that the output is stable across revisions of WebRender. I would be sad to lose this.

[gw3583]

@jrmuizel That's a fair point I hadn't considered. Will ponder this a bit more...

[gw3583]

@kvark How feasible do you think it would be to make the scene capture functionality also write out a stable representation of the scene-1-0.ron file? I guess this would semantically be writing a YAML file from the display list in the scene.ron file? That would probably give us a stable representation across WR versions. Or do you have other ideas that might provide that functionality?

[kvark]

@gw3583 the idea we've been discussing at All Hands is making a semi-stable structures defined that would be serialized to/from instead of RON. That would make the current YAML parser irrelevant, and all the conversion logic will by type-checked properly (but we still need to write/maintain the conversion code from the current internal representation of scenes into that stable definition). This is exactly what #2239 is proposing.

Another (probably simpler, but not as beneficial in the long term) solution would be to attempt to address #2583 (get internal RON -> YAML conversion with Wrench).

[gw3583]

Let's close this for now - we probably don't want to remove this completely until we have in place a solution for multi-frame recordings.