Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fast-forward implementation v1 #241

Merged
merged 2 commits into from
Jul 11, 2020
Merged

fast-forward implementation v1 #241

merged 2 commits into from
Jul 11, 2020

Conversation

Yuyz0112
Copy link
Member

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.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant