Fix scroll performance for widgets with huge content #5
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.
from original
Test case:
Added a test for a widget with huge content. On my machine, scrolling with either the keyboard or mouse is very slow and every scroll tick takes 5-10 seconds to process.
Fix:
It looks like lines[0] never contains an attr property (correct me if I'm wrong). lines.attr can however, so it seemed the intent was to call lines.attr[0] instead of lines[0].attr.
This check looks like it is related to the widget style attributes, allowing the _parseAttr to be skipped if this.style hasn't changed.
An assumption being made here is that lines.attr will be undefined if the content or width of the widget has changed, thus not allowing a skip to happen.
Another assumption that could be made is that lines.attr will always be at least length 1 if it's been cached (!== undefined). I wasn't sure if that's always the case, but I couldn't find a situation where it wasn't the case. If this assumption can be made, then the check can be simplified to