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've been profiling ember-table's performance during a css width transition that causes the table to reflow. There's a lot of work being done for intermediate animation states that just gets thrown away next frame. It would be nice if there was a way to tell ember-table not to do any reflow work temporarily. Then you could set that flag for the duration of your css animation.
The hotspots I've found so far are due to third party event generators, ResizeSensor and hammer.js.
You can avoid one ResizeSensor by never using t.loadMore so that an ember-table-loading-more never appears in your DOM. I recommend not using t.loadMore if you need liquid animations resizing an ember-table.
The other ResizeSensor lives in ember-thead and there's no current way to avoid this one. I temporarily disabled it by modifying the library and the Scripting work in the profiler drops dramatically during a resize animation.
hammer.js usage in ember-th also has no way to be avoided, short of not having a header on your table I guess. I similarly disabled this code to get a profiler snapshot.
Note the dramatic improvement in scripting and rendering time. We are operating within a frame budget here, so these milliseconds really matter. They compound frame after frame for the duration of the animation.
Before: 68ms
After: 47ms (31% improvement)
With ResizeSensor and hammer.js fully disabled:
With no t.loadMore, running stock ember-table v3
Apps could get smoother animations when using ember-table if they could disable ResizeSensor and hammer.js for the duration of the animation, and let those libs run once when the animation is done to 'catch up'.
It looks like hammer.js might have a configurable way to do this, by passing an enable function that could check a flag. I saw no easy way to temporarily silence ResizeSensor.
The text was updated successfully, but these errors were encountered:
I've been profiling ember-table's performance during a css width transition that causes the table to reflow. There's a lot of work being done for intermediate animation states that just gets thrown away next frame. It would be nice if there was a way to tell ember-table not to do any reflow work temporarily. Then you could set that flag for the duration of your css animation.
The hotspots I've found so far are due to third party event generators, ResizeSensor and hammer.js.
t.loadMore
so that anember-table-loading-more
never appears in your DOM. I recommend not usingt.loadMore
if you need liquid animations resizing an ember-table.ember-thead
and there's no current way to avoid this one. I temporarily disabled it by modifying the library and the Scripting work in the profiler drops dramatically during a resize animation.ember-th
also has no way to be avoided, short of not having a header on your table I guess. I similarly disabled this code to get a profiler snapshot.Note the dramatic improvement in scripting and rendering time. We are operating within a frame budget here, so these milliseconds really matter. They compound frame after frame for the duration of the animation.
Before: 68ms
After: 47ms (31% improvement)
With ResizeSensor and hammer.js fully disabled:
With no
t.loadMore
, running stock ember-table v3Apps could get smoother animations when using ember-table if they could disable ResizeSensor and hammer.js for the duration of the animation, and let those libs run once when the animation is done to 'catch up'.
It looks like hammer.js might have a configurable way to do this, by passing an
enable
function that could check a flag. I saw no easy way to temporarily silence ResizeSensor.The text was updated successfully, but these errors were encountered: