angular-ui / angular-ui/ui-scroll

isElementVisible performance

Ouverte
#220 4 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
Langage dominant
JavaScript
Étoiles
326
Forks
104
Métriques de merge des PR
Aucune PR mergée en 30 j

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

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.