Conversation
related to #6 Since the currently 'play at any time offset' implementation is pretty simple, there are many things we can do to optimize its performance. In this patch, we do the following optimizations: 1. Ignore some of the events during fast forward. For example, when we are going to fast forward to 10 minutes later, we do not need to perform mouse movement events during this period. 2. Use a fragment element as the 'virtual parent node'. So newly added DOM nodes will be appended to this fragment node, and finally being appended into the document as a batch operation. These changes reduce a lot of time which was spent on reflow/repaint previously. I've seen a 10 times performance improvement within these approaches. And there are still some things we can do better but not in this patch. 1. We can build a virtual DOM tree to store the mutations of DOM. This will minimize the number of DOM operations. 2. Another thing that may help UX is to make the fast forward process async and cancellable. This may make the drag and drop interactions in the player's UI looks smooth.
Alexays
pushed a commit
to ScreebApp/rrweb
that referenced
this pull request
Dec 11, 2025
`createCDATASection` is [only supported on XMLDocument](https://developer.mozilla.org/en-US/docs/Web/API/Document/createCDATASection#notes), not HTMLDocument. Doing so on HTMLDocument will throw an exception and break playback on the player. This change will log a "Failed to rebuild" warning to the console instead of throwing. Fixes https://sentry.sentry.io/issues/5222059335/?project=11276&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=issue-stream&sort=date&statsPeriod=90d&stream_index=11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
related to #6
Since the currently 'play at any time offset' implementation is pretty simple,
there are many things we can do to optimize its performance.
In this patch, we do the following optimizations:
For example, when we are going to fast forward to 10 minutes later,
we do not need to perform mouse movement events during this period.
So newly added DOM nodes will be appended to this fragment node,
and finally being appended into the document as a batch operation.
These changes reduce a lot of time which was spent on reflow/repaint previously.
I've seen a 10 times performance improvement within these approaches.
And there are still some things we can do better but not in this patch.
This will minimize the number of DOM operations.
This may make the drag and drop interactions in the player's UI looks smooth.