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

The Markdown preview is slow #3940

Closed
certik opened this issue Feb 21, 2018 · 5 comments · Fixed by #5901
Closed

The Markdown preview is slow #3940

certik opened this issue Feb 21, 2018 · 5 comments · Fixed by #5901

Comments

@certik
Copy link

@certik certik commented Feb 21, 2018

The whole JupyterLab is very responsive and fast, but the Markdown preview is very slow, it feels it takes like 1s to update the preview after I press a key to modify the source.

I mentioned it on Twitter and @Carreau replied that it's probably because it does a full render every-time, and a solution is to use a diff-aware Markdown renderer.

So I am opening up an issue for this.

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Feb 21, 2018

Hi @certik, the 1 second delay is actually deliberate. The idea is that we don't want to be constantly rerendering the markdown document (which might be expensive, and take unnecessary computing power). To combat this, we only render the markdown after you pause typing.

We can reconsider the amount of delay, but I think that some kind of throttling is probably important.

@certik
Copy link
Author

@certik certik commented Feb 21, 2018

@ian-r-rose if you try the editor, e.g., at http://markdown.pioul.fr/, you will see that the preview is immediate. So I know it is technically possible, and at least for me, that is the preferred and expected behavior.

But as you say, some users might prefer to lower the responsiveness to have more computing power, and I think there should be an option for that somewhere in the settings to enable that.

@Carreau
Copy link
Contributor

@Carreau Carreau commented Feb 21, 2018

Would it be possible to adapt the rendering delay to be a function of the last rendering time ?

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Feb 21, 2018

That could work. One question in my mind is how to handle MathJax rendering. In any kind of markdown with equations, that is likely to be the slowest part. MathJax 2 does not provide an easy way to hook into when the rendering is done (though I think you might be able to do it by adding a signal in the event queue).

@ellisonbg
Copy link
Contributor

@ellisonbg ellisonbg commented Feb 24, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants