angular-ui / angular-ui/ui-scroll

isElementVisible performance

Open
#220 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
326
Forks
104
PR merge metrics
No merged PRs in 30d

Description

The rows we are displaying are complex and thus the digest cycles are pretty expensive. By profiling some of the code, we figured out that isElementVisible triggers many browser style recalculations (forced reflow), see the attached picture. When I changed the isElementVisible like bellow:
```
function isElementVisible(wrapper) {
return true && wrapper.element[0].offsetParent;
//return wrapper.element.height() && wrapper.element[0].offsetParent;
}
```
then it suddenly became more efficient. From what I understand, this is for the rows that have an initial height of 0, but in our case all the rows always have the same fixed height, and are never hidden.
I'll be happy to submit a pull request with a parameter that prevents this check, but I would like to know what form it can have. For example, we can have a rowheight attribute that sets a fixed value for the row height. If so, and if we use this attribute during calculations, can this be used to reduce the manual calls to $digest, like in processUpdates or resizeAndScrollHandler? In the later, I'm not sure what a $digest needs to be triggered, particularly if no rows have been inserted/deleted. But I might be missing something :-)
VisibilityWatcher

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.