Description
Describe the bug
There seems to be a noticeable performance hit for media over 1 hour - in this case 2h 42 min video.
To Reproduce
Prep - get a transcript for along file
these are the steps I followed, irrelevant for the bug itself, but helpful to setup problem, you can skip
- I got this video from vimeo
- used pietrop/electron-video-downloader to get the video, (electron wrapper to youtubedl)
- created a video over 2 hours, closer to 3 by concating shorter video with ffmpeg (ffmpeg-remix on an mp4)
- create transcript using autoedit.io using pocketsphinx option for STT
- exported autoEdit2 json once transcript is ready
Steps to reproduce the behavior:
- get a long media and STT json transcript
- Go to storybook demo page
- Click on 'import transcript' select 'autoEdit2'
This is the json I used
three-hours-sample.mp4_26_04_2019_15-12-51.json.zip - Click on 'play'
- Scroll down to text
- Click on a word, and start typing
- See error - there's a noticeable lag between when you type and when you see it on screen
Expected behaviour
No lag for videos over 1 hour, same responsiveness as for video under 1 hour.
Screenshots
Desktop
- OS: Mac OSX 10.13.6 - High Sierra
- Browser: Chrome Version 73.0.3683.103 (Official Build) (64-bit)
- Version:
@bbc/[email protected]
Additional context
Not sure what's the issue 🤷♂️
Might be mostly to do with draftjs?
Since we use persistent data and aggressively avoid re-rendering, the size of the document should generally not be a problem unless there is a bottleneck somewhere.
https://reactrocket.com/post/draft-js-best-practices/
A feature-rich draft.js editor with lots of decorators and custom block components can easily cause performance issues, especially for large documents. Draft.js doesn’t do anything special to prevent unnecessary rendering of these components, you can however optimize by using the shouldComponentUpdate method, which puts you in control of when your components re-render.