Multiple Frames, Multple Captures.....

[greggman]

This is obviously not important now but ....

At the moment the UI has multiple panes. A pane is given something to show (ReplayBuffer, ReplayTexture, ReplayPipeline etc...

If you capture 2 replays, inspect stuff in the first, then switch to another, some of the panes don't update beacuse they are still viewing the textures, buffers, from the first replay.

This is because the 2 replays are entirely independent. The UI has no idea that the 4th texture on the 10th command in replay #1 is the same as the 4th texture on the 10th command in replay #2, or any other command.

Maybe there should be some way to get multiple replays from the same app?

In others, now it's

class Replay {
   object: [];
   commands: [];
}

but it maybe needs to be

class Replay {
  commands[];
}

class Capture {
   objects: [];
   replays: [];
}

Were you can keep calling traceframe and it will keep adding replays and/or new objects.

[greggman]

maybe it's not important to have traces share resources but .... one idea would be to create a UUID in the registry and put it in the capture. Then in loadReplay, change the siguature to loadReplay(trace, oldReplay). If the uuids match then, have the serial numbers match too (generate serial numbers on object creation if they aren't already) so they'd be stable, then you could merge any matching objects from the old replay into the new replay so they'd be the same objects?

Maybe it's not important? It seems like it would be nice to capture multiple frames and observe changes to some resource over time but there needs to be some association between traces for that to happen.

[Kangz]

The UUID you're suggesting would be the traceSerial that's currently used by the capture. We could merge traces this way eventually by splitting off the object management of replay out (though there's some complexity as it means objects now have multiple initial states that must be reset on replay start, so IDK how we would handle that)

[greggman]

I'm not sure what you mean by the UUID I'm suggesting is traceSerial. If I capture a trace from one page and capture a trace on another page from something else and I load both traces into the debugger their traceSerials will conflict.

Where as if I capture two traces on the same page without refreshing the page their traceSerials will match. But the UI/replay won't be able to know "these 2 traces come from the same session" vs "these 2 traces are not related".

So, my suggestions was create one UUID and put it in the trace. Every trace from the same session will have the same UUID and so now the UI/replay can know when traces are related and when they are not. If they're from the same session then they have the same initial states.

[Kangz]

Yeah you guessed why I suggested traceSerial was the UUID: Seb brought up the idea of capturing multiple frames of the same running application and that would have worked, but not for captures of different runs of the applications yeah. What you suggested could work but we still need to keep track of the initial state of the replay for each trace independently.