You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was testing some settings and edge cases of the PDF printing support using a ~50 slide presentation.
In the Chrome devtools I noticed that the flame chart of a performance recording showed a lot of forced layout spans.
I looked into the areas where this happened and applied the advice to improve time spent on layout:
limiting DOM access
batching reads at the start of a frame
batch writes after reads
When building this library with these changes, and testing again with the presentation I was working with, performance improved and there were less forced layout spans in the performance flame graph.
The code should still do the same functionally.
Promises and requestAnimationFrame were already used elsewhere and async/await gets compiled to promises, so browser compatibility should also remain the same.
@hakimel after f576b98 there was a merge conflict with this branch. I resolved it, and by doing that I saw Reveal.layoutSlideContents and Reveal.slideContent.layout next to each other. One handles stretch layout, the other handles text fit. Could they be combined in Reveal.slideContent.layout or would that not work in some cases?
Does the current code look good to you? (It might be easiest to review commit by commit.)
Regarding the layout methods, if I remember correctly the code in Reveal.slideContent.layout only needs to be called once when the slide loads, whereas Reveal.layoutSlideContents needs to be invoked whenever the browser viewport is resized. The naming is confusing—it might be better to rename the prior method to something else.
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
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.
I was testing some settings and edge cases of the PDF printing support using a ~50 slide presentation.
In the Chrome devtools I noticed that the flame chart of a performance recording showed a lot of forced layout spans.
I looked into the areas where this happened and applied the advice to improve time spent on layout:
When building this library with these changes, and testing again with the presentation I was working with, performance improved and there were less forced layout spans in the performance flame graph.
The code should still do the same functionally.
Promises and requestAnimationFrame were already used elsewhere and async/await gets compiled to promises, so browser compatibility should also remain the same.
Thank you for all the work on this library!