Closed stevenbird closed 9 years ago
As an alternative to using hundreds of megabytes of memory storing project XML snapshots to facilitate rewinding, I propose https://github.com/antimatter15/whammy
One minor (major?) caveat is that it would record just what is on the screen.
Unfortunately, real-time arbitrary slider-based navigation with the ability to inspect the state completely is flat out impossible in the general case without tons and tons and tons of memory to store every single state of Snap! Whammy won't work for our purposes since it can't record the contents of stuff not on a <canvas>
(the graph display is on an <svg>
).
What could be done is limited rewind (only the last n states) and/or resimulating. Thankfully, programs can't be self-modifying, so the latter is probably doable fairly quickly. (Though I doubt it can be done in real-time.)
What about generating a movie file from a logfile. That can be navigated using a slider.
That's true, but I don't think we can do it from within the browser. As I said, Whammy won't work, and rendering SVG to canvas and then encoding that would be far, far too slow if at all possible.
There's no requirement for a browser to be involved, and it doesn't matter if the processing has to happen offline. The requirement is to be able to visualise a user session, and navigate within it.
Well, in that case, an option would be to use a window recording program to capture the browser window. Writing our own special Snap-oriented solution to this would be silly, I think.
We can't do it within an individual user session given the bandwidth requirement. Can we do it from a logfile? E.g. have a shell script invoke a screen capture program and also invoke Chrome with the filename or URL on the commandline, and have it automatically replay the logfile, then stop the screen capture once the logfile has finished playing?
Wait, I meant it as a local thing. Load log file, start recording, start playback. No special bandwidth requirement.
So we just need to be able to do this in batch mode.
I'm missing something. Why does it need to be batched?
Only if it is slow. The researcher viewing the log needs to be able to navigate backwards and forwards, and so I'm anticipating a batch process to convert logfiles to videos, and that the researcher will access the videos directly.
You're right, it would be slow, since the researcher couldn't rewind until after they had seen the entire thing (though after they could view it as they please). Batching it might be possible on *nix with ffmpeg for recording, though I can't seem to find a way to automatically terminate the recording after the playback is finished (ffmpeg needs someone to send it a signal to stop).
Load a logfile and replay the block events. Permit speed-up of playback.