Comments (7)
When this is being refactored, it might be valuable to separate three distinct concepts here?
Right now we have the "storage of events", which are then converted in "playback" actions, which are then executed by timing logic. However, these three are tightly integrated, which makes it a bit hard to use one of the specific elements but not the others.
In the current code, replay/timer.ts
is both concerned with storing a list of actions, and timing their playback, while replay/index.ts
mostly handles generating actions which modify a output iframe but is also dependant on certain timer functions.
For example for the case of live streaming it'd be nice if I was able to reuse the event storage and playback action generation, but supply my own timing logic. Or, another example, if I wanted to output to multiple iframes, I'd like to still use the event store but have multiple replay functions use it. I'm also interested in allowing the use of a more abstracted clock for the timing logic so that other time-bound elements may tie in to it.
Splitting the concepts up might look like this:
- Event store: Just stores the events. It may do some preprocessing, but it isn't directly concerned with actually replaying anything. It provides a method to add events, and one to retrieve events between two timestamps, and probably an emitter to notify other objects its contents have been updated.
- Replay renderer: Only handles actual replaying of events, doesn't store them or determine when they should be replayed. Is given an output element and an event store, and provides a single method
render(time: number)
which renders the replay in its output element for the given timestamp. - Timer loop: A
requestAnimationFrame
loop which calls therender(time: number)
method of the replay renderer to actually make it play back. This would then also be the only part to be connected to the playback controls in the interface.
The event store would then be the place where these checkpoints (which would basically be full snapshots) are (pre)computed, so that it can return a small number of events for the replay rendererer to render to go to a certain point in time.
The replay renderer should remember the last timestamp it rendered, and only request a delta from that timestamp instead of having to render from the very first full snapshot. It might also do some higher level caching by storing a clones of rendered snapshots so it won't have to reconstruct them.
I know this is only laterally related to this issue, but it might be useful to think about before effort is put into building the checkpoint logic so that if this is something we'd like and want to consider, one can somewhat account for it while tackling this issue.
from rrweb.
@remisharrock Thanks, I'll take a look.
from rrweb.
This would be a great feature IMO. We plan to use rrweb for product demos and definitely take advantage of it.
from rrweb.
Could you try the CODECAST player scrolling https://codecast.wp.imt.fr/codecast/ maybe you can find a way to have fast scrolling to any point in time in the source code https://github.com/France-ioi/codecast ?
from rrweb.
I found the name of the library that enables the fast seeking through the recording: Redux-Saga, as you can see in this file : https://github.com/France-ioi/codecast/blob/master/frontend/player/sagas.js
It says that
// An instant has shape {t, eventIndex, state},
// where state is an Immutable Map of shape
My guess is that the shape could be a VirtualDOM ?
Also the code has a lot of synchronization with the audio being played simultaneously.
By the way, you can try the recorder here https://codecast.france-ioi.org/v6/recorder by clicking the "guest" button , authorizing the use of your microphone, clicking the record button (red "start recording" and by typing some code in the editor (also selecting text, scrolling, compiling if it's C code and executing step by step etc...)
Interesting here: when you click the pause button you can go back a little bit in the recording and start from this point.
Another thing interesting here: when you click the stop button, the audio is being compressed to mp3 client-side (using a javascript mp3 encoding library) ;
Finally, when you click the save button, the JSON containing the events and the mp3 file is being sent to a server and you can play back the recording using the generated URL (playback link).
Can you try it and tell me what you think ?
Also try to seek during playback and also drag and drop the time cursor, you will see immediate changes, which I think is pretty cool ;)
Hope that you can find a good solution from this project, in order to have this kind of reactivity when you seek through the recording during playback !
from rrweb.
Also it looks like another dev has a slightly more updated CODECAST project (forked) and is working on it right now here: https://github.com/pkrll/codecast
from rrweb.
Any news on checkpointing or an approach to fast forward in any point in time very fast?
from rrweb.
Related Issues (20)
- [Bug]: use blockSelector to mask img record will throw error: e.matches is not a function HOT 3
- publish well-formulated and concise types HOT 1
- [Bug]: maskInputFn is not called on inputs
- [feature request]: Record/replay css animation's `currentTime` HOT 6
- [Bug]: progress bar not updating when adding event asynchronously using addEvent
- [Bug]: Added nodes not showing up HOT 1
- Changes the you made may not be saved HOT 1
- [Bug]: CSS `all: unset` incorrectly expands in `events.json` recording HOT 1
- [Bug]: Repeat menu
- [Bug]: Stopping recording causes all insertRule hooks added after record start to drop
- [Bug]: how i can record iframe content HOT 4
- Sanitization/Renaming for Security in Snapshot vs Replay reconstruction HOT 1
- [Bug]: Failed to rebuildFullSnapshot HOT 3
- [Bug]: Firefox Addon causes "This page is asking you to confirm that you want to leave" on all navigation HOT 1
- [Bug]: isParentRemoved lags by 1 to 3 seconds on pages with lots of nodes
- [Bug]: rrweb/rrwebPlayer scrubbing not working?
- [Bug]: Chrome tab crashes while replaying
- [Feature Request]: Event Data verifier
- [Feature Request]: Specify allowed origin for cross-origin iframe recording HOT 1
- [Bug]: Uncaught DOMException: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': The canvas has been tainted by cross-origin data.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rrweb.