To keep you updated, it’s the reflow for sure and it’s caused by pointer events reading the offsetWidth from the DOM. It’s a common problem of javascript apps with a lot of elements. In this case we have about 16K elements. Every time the javascript code reads el.offsetWidth it causes a reflow (see console in Chrome with F12). We are still experimenting to reduce access to offsetWidth as much as possible. Some optimizations are already in the upcoming build. If you put the large panel on Page instead of in a resizable and movable form it also reduces the reflows. I hope we’ll be able to reduce them quickly.
Adding the Big user control to a page would change the Application behavior :(, as a first step I will give it a try using the upcoming release, hoping it becomes “usable” with few Rows.
To create a work around, having a ListviewPanelItem (VWG concept : represent a list view item that can have a panel), and also a listview Add function which accepts a user control (also VWG concept) would help me to reduce the rows displayed at first glance.
I will create a new support entry for these.
Luca, thanks for the update.
Luca, I tested with the latest release Wisej-1.4.32, but couldn’t see a noticeable improvement. My hopes are now toward the enhancement request WJ-8485, which would allow to reduce the number of elements (by presenting a “compact” grid where the user click rows for the full detail “Big UserControl” been shown).
Thanks for the support provided .
I know. The problem is the thousands (I think the app counted 16,000 elements) of small controls that act as controls on the client reacting to pointer, etc. and at a very low level in the code there are lines that use the dom.offsetWidth property and browsers always cause a reflow when reading the dimensions and other related properties. We are testing to see how to cache it to reduce the reflows. However, at one point if you increase the rows it will still hit a performance bottleneck. What about using popup panels to show the details when either hovering or clicking? I any case, the reflows experimenting is still ongoing.
I can understand the technical problem. My idea was to allow visibility of one detail Row at a time. I expect hovering based display to not be smooth enough, as rendering of 1 row takes a little too long. To create the “compact” row i’m in need for the ListviewItem to accept controls in columns.
In all case, I think that the re-flow caching experimenting, if succeeding, will be beneficial to the product as it will increase the rendering speed for all type of projects.
