Speed advice

0
0

Hello,

I have a Form filled with ROWS defined as a User-Controls. Each ROW is constructed by assembling other User-Controls. There are many small User-Controls with vertical text. The total amount of user-control assembled can easily be around 100 per ROW.

Take a look at the attached screenshot.

I would like to hear your advice regarding a speed improvement for displaying it.

From what I can see, the creation itself is fast, but somehow the time between the creation is finished and the time it’s ready in the browser is substantial.

I already tried creating them using the Background task technique like in your sample, and it’s the rendering which is delayed.

When few rows (5 to 10) have been created and added, manipulating the interface is becoming slow.

Can you give me an advice on how to create it in a way to eliminate those effects ?

Thanks.

Regards.

 

Attachment
  • You must to post comments
0
0

Hello Eric,

To keep you updated on this:

  • We have been unable to remove the usage of offsetWidth from the core code, it’s vital to the correct functioning – and it’s actually not the real problem.
  • I have rebuilt a similar (actually simpler) sample in just html in jsfiddle with zero reflows and the UI is very slow with plain HTML and CSS

But…

I have removed the rotation from your sample and the same code with thousands of controls is actually quite fast now. See quick video:

https://www.screencast.com/t/WhXnDyUc

I’m looking to see how to set the rotation globally instead of control by control. You can also simply some of the complex composite controls by consolidating them into a single control and using an html template to render the inner content.

With C# is quite easy to use string interpolation to bind data to an HTML template.

I will update this thread with the rotation solution.

/Luca

 

 

 

  • Eric Mathay
    Hello Luca, From your video, I can see that effectively the usability after the controls creation is greatly improved and would be usable by the users. So that rotation is adding to the problem :( One hand you tell me plain HTML and CSS is slow and the other hand you propose me to use an HTML template -> will this not come to the same usability problem ? I tried to explore your “string interpolation to bind data to an HTML template” but I have really no idea on how to achieve that. Regarding the rotation problem, could a new property like “Orientation” -> vertical/Horizontal or Rotation -> Angle, added to the textbox/label be a solution ? Would it still create slowness ? As last resort, based on the Blog “Adding Panels (and much more) to ListViews”, I could re-design the UI to present a compact view, which once expanded would show the big control. Not what the users are looking for, but at least a solution. In all cases, big thanks for taking care of it !
  • Luca (ITG)
    The rotation problem is not a wisej problem or it’s not related to how the css is set. It appears that the browser increases the work it has to do when there are too many rotated objects. I tried to rotate the entire panel but it’s still too slow. It explains why I had the same problem with plain HTML without any reflow. The html suggestion will not solve the rotation speed problem, but it can make the creation of the panels a lot faster. I’ll send you an example of html with string interpolation.
  • Eric Mathay
    Hi Luca, Did you find time for a small example of html template with string interpolation ? With the latest Wisej release, which adds features to the listview, I would like to test implementing the creation of one big row detail when hovering over a “compact” listviewitem. I would like to compare the traditional way and with the HTML template. I have seen that the listview has an event “ItemMouseHover”, but it doesn’t fire.”MouseHover” event is firing properly but doesn’t allow for to know which Item was hovered. Is it fully implemented ? Any idea ? NB: I already see some perfs improvement, but don’t know if it’s coming from the latest Wisej release or the latest Firefox quantum.
  • Eric Mathay
    Hi Luca, Now that Wisej allows Listview rows to contain controls, I have splitted the “Big” row and inserted the parts into the Listview Columns. This gives a far better responsiveness even that the rotation has been kept.
  • You must to post comments
0
0

The slow down is caused by reflows triggered by reading offsetWidth repeatedly. We tracked it down to the way the user control is setup in our javascript library and it should be easy to fix. I will have more details with a dev build and possibly a quicker workaround soon.

  • Luca (ITG)
    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.
  • Eric Mathay
    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.
  • Eric Mathay
    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 .
  • Luca (ITG)
    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.
  • Eric Mathay
    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.
0
0

Hi,

Just to mention, I tried removing the StyleSheet control from the user-control doing all the small vertical texts.

The creation time stays quiet the same, the rendering time delay also, but there seems to be a slight amelioration on the reactivity using the scrollbars.

  • You must to post comments
0
0

I downloaded this and tried it as well. Something seems to be bogging down the browser – even after all rows are rendered I cant even use the scrollbars on the window.

  • You must to post comments
0
0

Hello Luca,

From what I experimented, it seems that the browser doesn’t really plays a role. I tested with the 3 major ones, IE, FF, Chrome, and the rows creations is around 0.3 secs for 10 rows for all of them.

More rows added, more time it takes to render them and worthier gets the responsiveness of the browser interface.

May be the reflow is ok, and it’s due to the browser latency because of the many text rotations. I did them using a stylesheet control.

I also don’t see a real speed increase being on the Dev environment or on the full power of the deployed Server.

I did a self-contained test app which I tried to not de-structure too much so we keep a similar code structure.

 

Regards.

Attachment
  • You must to post comments
0
0

Chrome? Would you be able to put together a sample app that creates a similar structure? The problem seems to be the browser rendering and reflow.

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.