Identifying Web 2.0 Rendering Speed Problems and Regression

[Austin_Clow]

Hello Friends,

I have been working on converting an extremely large Web 1.0 project to Web 2.0. I have made a lot of progress and have learned a lot. There are a lot of things that are broken. I want to have a discussion on some of the speed issues of Web 2.0 and hopefully find some insight into how I can refactor some of my code.

The Setup:
I have a WebPage class that embeds about 7-9 WebContainer classes, each of those WebContainers have a WebListBoxes, and maybe 3-5 more embedded WebContainers with more WebListBoxes and HUNDREDS of custom WebUISDKControls that mimic WebTextFields (so I can have an EnterKeyPressed event).

The Problem:
This WebPage takes approximately 3-4 minutes to render on the screen. It takes about 1 minute for the screen to go white, then about 2-3 minutes more for it display any of the content.

Compared to Web 1.0
In Web 1.0, this same WebPage takes about 1.5 seconds to load.

The Question
What are some of the controls that you have identified as causing speed issues? Additionally what have you discovered are good practices for loading things on screen? Like should we avoid using the .style property on controls? (I have hundreds of these modifications to make things Look right such as positioning toolbars)? Are using WebSDKUIControl actually the problem? Should wait for “Shown” to modify .style? Should I avoid using WebListBoxes?

If anyone has any idea where my bottleneck might be, I would love the tips so I can run better tests.

Side Note
For those of you who have not yet converted your large project to Web 2.0. I sincerely believe you should NOT do it now. The number of issues that need to be fixed in the Conversion process alone are insurmountable and frustrating.

[Louis_D]

I reported the same issue. My feedback case was reduced to only the side issue with webimageviewers within a rectangle in a container. I was left with the bitter impression that noone at Xojo wanted to hear about this problem. You only need a few controls to see the issue. I cannot understand why it was ignored!

In the mean time, I discovered that some controls execute their opening and shown event code at least twice. I retrofitted my containers with boolean properties and a little check to avoid executing twice (and in some cases a bit of code to reset the property). It does help performance somewhat, but there is clearly a bottleneck issue in Web 2.0. While this workaround can be used on fairly simple pages or containers, it is probably impractical in your case. Right now, my productive application remains on 1.0 (2019 R3.1) and the web 2.0 is just an internal alpha. It is simply unusable due to this issue.

• Several controls have the problem. It is evident on popupmenus (major bottleneck here!), text fields, and a few others.
• I discovered that changing the style of a control comes with a performance cost. So I spent an inordinate amount of time fiddling with my theme to design specific styling for my controls. There is much less performance cost going this route, at least in my specific case.

[Ivan_Tellez]

@Austin_Clow

For those of you who have not yet converted your large project to Web 2.0. I sincerely believe you should NOT do it now. The number of issues that need to be fixed in the Conversion process alone are insurmountable and frustrating.

Web 2.0 still looks like a Beta at much. it is a real shame they decided to kill 1.0 with 2.0 in that state.

Anyway…

@Austin_Clow

If anyone has any idea where my bottleneck might be, I would love the tips so I can run better tests.

Yo can test your app with chrome, open the developer tools, go to the network tab and check the traffic. Maybe you can get the idea of where is the problem.

[Bryan_Hutson]

@Austin_Clow

What are some of the controls that you have identified as causing speed issues?

I’m seeing very slow WebContainers as well in Web 2.0. I usually create WCs that mimic listbox rows and dynamically embed them in a larger WebContainer that the WC ‘rows’ can be scrolled within. In Web 1.0 I could load 100 rows in less than 2 seconds. Right now in Web 2.0 I’m seeing 13 second load times… but I anticipate this to improve as Web 2.0 matures.

@Austin_Clow

Additionally what have you discovered are good practices for loading things on screen?

I allow all simple items on the page to load first along with a ‘loading…’ label and progress wheel. Once the page Shown event triggers, I single-fire a timer that loads the custom WC listbox rows and hides the progress wheel and label when finished. It doesn’t make things any faster, but seems a bit faster.

@Austin_Clow

using the .style property on controls?

I use the .style property to change selected/unselected state for my custom rows with only a slight performance hit. I also set .style in the Opening event without any problems.

I can’t help much regarding WebSDKUIControls or WebListBoxes unfortunately.

[Hanif_Saad]

Austin,
I am wondering if these things happen also if you create the controls dynamically at runtime and use EmbedWithin to attch them to the web page; rather them adding
them manually using the IDE

[Louis_D]

Hanif, This is a good idea. However, I tested both ways. No significant difference that I could detect.

[Attilio_Punzi1 (Attilio Punzi)]

I too have noticed a drastic drop in performance. Not so much on WebSDKUIControl but just on Xojo controls. WebContainers are unusable because they slow down the loading of the entire page. Looking at the browser console I’ve also noticed that WebPopupMenus take much longer to load.
Also in the console some events of controls appear that I don’t find on screen nor in the DOM. For example:
QG8tsr.shown 181ms
QG8tsr.Dismissed 822 ms

I think it’s the webdialogs fault but I haven’t investigated the problem yet.

@Louis_D

In the mean time, I discovered that some controls execute their opening and shown event code at least twice.

Did you happen to use the tag system? I noticed that compared to web1.0 if you set for example Session.HashTag="", the HashTagChanged event in web 2.0 is triggered. I didn’t understand if this is a bug or if the operation has been changed.

[Louis_D]

I have not used that particular function. It does make sense to me however that when setting the value, the websession (or webpage).valuechanged event would trigger, regardless of what value is set. I don’t see this as a bug. There are several changes in web 2.0 that we need to adapt to, not all of them are bugs. Some of them are just decisions that I just can’t understand. But I digress again…

[Austin_Clow]

@Hanif_Saad

I am wondering if these things happen also if you create the controls dynamically at runtime and use EmbedWithin to attch them to the web page; rather them adding
them manually using the IDE

I have a mix of both actually.

As it is right now, adding WebContainers to other WebContainers in the IDE allows the LockLeft, Right, Top, Bottom to function correctly; while using .embedWithin does not. So they aren’t substitutes. I can’t imagine what my project would look like if I used .embedWithin for most of the WebContainers, you’d have an even more unusable web app.

Regardless, using .embedWithin or adding the WebContainer in the IDE produce the same speed issue. It is EXTREMELY slow.

The advantages to using .embedWithin is that you can delay when the embedding happens in order to make it appear like things are loading faster, but that doesn’t change the fact that .embedWIthin on Web 1.0 was incredibly fast compared to 2.0.

[Brock_Nash]

61593 - Embedded WebContainer’s Controls not locking properly
feedback://showreport?report_id=61593

Unfortunately Web2.0 needs a lot of love yet, especially around WebContainers and performance issues. Pretty much all my apps have only one or two webpages and then dynamically embedded and nested container controls

[Austin_Clow]

@Brock_Nash

Unfortunately Web2.0 needs a lot of love yet, especially around WebContainers and performance issues. Pretty much all my apps have only one or two webpages and then dynamically embedded and nested container controls

Same.

[Greg_O_Lone]

@Attilio_Punzi1

QG8tsr.shown 181ms
QG8tsr.Dismissed 822 ms

FWIW, the majority of the code that causes these differences is user code, as in, the code path is identical on the server side except for which event handler fires.

Now there are some events which are always sent from the browser to the server because they send important information that you would otherwise expect to be there… For instance, we always send text changes in a text field regardless of whether you implement the ValueChanged event because you might refer to the value in the pressed event of a button.

Also, keep in mind that our apps use cooperative threading so if the app is doing something else when an event comes in from a browser, there may be a delay just because it has to wait for it to finish.

[Attilio_Punzi1 (Attilio Punzi)]

Thanks Greg as always for the explanations. By now you can find everywhere my feedback and posts on the forum because I’m trying to do as many tests as possible to make the most of the 2.0 in which I believe so much. For this reason I thank you for your excellent work. I hope they can be useful to everyone to find any problems and optimize future releases.
For the discourse of performance I created today a feedback because in my opinion there is something that escapes in the whole new framework. At first I thought it was the fault of the events Show, resized etc of the various controls but the drop in performance that you feel is something deeper.

@Greg_O_Lone

Now there are some events which are always sent from the browser to the server because they send important information that you would otherwise expect to be there… For instance, we always send text changes in a text field regardless of whether you implement the ValueChanged event because you might refer to the value in the pressed event of a button.

This is perfectly clear and sensible. I have also implemented this logic in the various WebSDKUIControls to maintain data validity between javascript and xojo, otherwise when trying to access the control properties the data is invalid.

[Austin_Clow]

I created a test project that calls .embedWithin 200 times for various controls. I created 25 tests. While making the test suite, I came across something interesting. My placebo case (which embeds 200 empty WebContainer views) is twice as slow if run from a page that already has 55 WebUIControls on it.

To be clear, I used the Clock (stop watch mode) on my iPhone to time each of these .embedWithin methods. I noticed that as I created more WebButtons on the test page to run the tests, the times kept changing. What was happening was, they were getting slower because as I added more objects onto the Test page, the .embedWithin became significantly slower.

I attached two pictures of my project to see what I mean by 55 buttons already on the page and what the test case page looked like.

Why 200 Times?
The purpose of doing this 200 times was initially to simulate what my Web app does. It embeds lots and lots of controls. My app is still much slower than these tests and I am hoping to figure out which combination of controls is causing the problem.

SIDE BAR
My project when run still doesn’t show the correct Button colors. I have no idea why. The colors show up properly in the IDE.

[Austin_Clow]

I downloaded your test projects and I find the degeneration worrying.

[Greg_O_Lone]

@Attilio_Punzi1

This is perfectly clear and sensible. I have also implemented this logic in the various WebSDKUIControls to maintain data validity between javascript and xojo, otherwise when trying to access the control properties the data is invalid.

FWIW, the framework should be forcing the contents of all WebTextFields on a page to finish sending their data when the button with the Default property set to True is pressed.

[James_Sentman]

I know that in web1.0 if you implemented a lot of open or shown events in the controls each one would cause another callback to happen to the server and it took quite a bit of time. I wanted to do some cleanup of layout by injecting some javascript in the Open events of many small objects and it made things REALLY slow down. I wonder if something similar is happening here as you manually lock all the edges of the container controls. Are you doing that from inside the Open event or whatever the new equivalent is? If you remove those event implementations temporarily does the speed increase? Even though I know that is not a solution, but it would be interesting to know if that was the problem. For all I know the open events are cascading when things are on a container control causing hundreds or more individual hits. Another reason that it should be using a web socket for bi directional communications and not a server socket for server updates but making individual hits in the opposite direction But thats just me… I don’t know if that has anything to do with it or not but it definitely made stuff in 1.0 a lot slower to implement any event that had to call back during the loading process. If we can narrow down whats causing so much extra work it will let them get started fixing it faster.

[Attilio_Punzi1 (Attilio Punzi)]

If you download the examples I provided in feedback 63176 linked above, you’ll see that events have nothing to do with it. Initially I thought that was the problem too but from what you can see in the examples, the thing that slows down the most is the creation of the objects. I do nothing but dynamically create 15 Webcontainers that assign simple text to standard xojo controls without Shown/open events etc and without drawing them. The loading times of the Webpage looking at the browser console go from a few ms in web 1.0 to a few seconds in 2.0.

[Attilio_Punzi1 (Attilio Punzi)]

@Greg_O_Lone

FWIW, the framework should be forcing the contents of all WebTextFields on a page to finish sending their data when the button with the Default property set to True is pressed.

I think we are saying two different things. I meant that many of my WebSDKUIControls that implement text fields, calendars, tables etc at each event that occurs on the browser that changes the data (e.g. the cell of a table) it sends the changes to the server. In this way when you go to perform some operation on the data server side they are always valid. Regardless of what is pressed. Unfortunately I can’t understand some of your explanations, but I think it’s my fault since I don’t know the framework functioning.

One last thing, can you confirm that when I set Session.HashTag="" the trigger of the HashTagChanged event is intentional and not a bug?

Thanks