OpenUI5 version:
latest, also tested with 1.60 and 1.52
Browser/version (+device/version):
Chrome, IE11
URL (minimal example if possible):
https://jsbin.com/yixarilija/edit?output
Steps to reproduce the problem:
Any other information?:
The style calculation of the sap.m.Table takes a lot of time, especially in Internet Explorer and when it鈥檚 used within the sap.f.FlexibleColumnLayout. As far as I know the event onColumnResize of sap.m.Table is triggered for each column, which causes in several times of re-rendering of the table. So if you resize a column of the FlexibleColumnLayout by pressing the layout arrow, the column resize event is triggered each time the table width changes, which is very often because of the slide animation.
Is there a way to improve the rendering behavior of the sap.m.Table?
Thank you,
Julia
Hello @uifivvy ,
Thank you for sharing this finding. I've created an internal incident 1970521106. The status of the issue will be updated here in GitHub.
Regards,
Tereza
As far as I know the event onColumnResize of sap.m.Table is triggered for each column, which causes in several times of re-rendering of the table. So if you resize a column of the FlexibleColumnLayout by pressing the layout arrow, the column resize event is triggered each time the table width changes, which is very often because of the slide animation.
This is not correct. Table#onColumnResize gets triggered by columns when breakpoints(minScreenWidth) of columns are hit. It is true that this method will be called several times but there is a 200ms throttling for the rendering. You can simply add a breakpoint
to Table#onAfterRendering method and will see that it hits only once when you press the arrow.
On the other hand, when I do the profiling I see that there are many forced reflow from the FlexibleColumnLayout. I forward this to the responsible team. Thanks for your feedback!
Internal backlog item is created to investigate reasons of this issue further. You will be informed again after BLI is finalized.
Hello @uifivvy,
Our BLI for performance improvements of FlexibleColumnLayout is done.
Merged change: https://github.com/SAP/openui5/commit/762c195aeae6b2cdc5200dd048274d320a1b3c2b
Regards,
Iliana
@IlianaB Thank you for the update. Caching the calculated width would definitely help. The FCL itself seems to be performant enough (e.g. FCL without much content) but as soon as the FCL contains controls that are typically used together, such as f.DynamicPage, m.Table, and uxap.ObjectPageLayout, navigating or changing the column layout (setLayout) causes massive frame drops.
From: https://openui5nightly.hana.ondemand.com/test-resources/sap/f/FlexibleColumnLayoutWithRouting.html:
Apart from the obvious optimizations that applications can apply (e.g. no sync XHR), it would be nice if the corresponding control authors could identify remaining performance bottlenecks to improve the overall performance. For example, can m.Table replace rerender() with the asynchronous invalidate()?
Most helpful comment
@IlianaB Thank you for the update. Caching the calculated width would definitely help. The FCL itself seems to be performant enough (e.g. FCL without much content) but as soon as the FCL contains controls that are typically used together, such as
f.DynamicPage,m.Table, anduxap.ObjectPageLayout, navigating or changing the column layout (setLayout) causes massive frame drops.From: https://openui5nightly.hana.ondemand.com/test-resources/sap/f/FlexibleColumnLayoutWithRouting.html:
Apart from the obvious optimizations that applications can apply (e.g. no sync XHR), it would be nice if the corresponding control authors could identify remaining performance bottlenecks to improve the overall performance. For example, can
m.Tablereplacererender()with the asynchronousinvalidate()?