WebGL progress bar not updating?

Hello!

I've built a custom WebGL loading template, but essentially I just reskinned the Default template. For some reason, my builds only ever show progress up to about the 15-20% mark, hold there, and then snap to fully loaded once the game is completely loaded (see screenshot below).

I've noticed a couple other Unity games I've found hosted elsewhere are doing this too, but the original AngryBots Beta demo shows loading progress perfectly.

I've copied the UnityProgress.js exactly from the default template (and I think the default template is also not showing progress for me), so I'm really not sure what's wrong. I even compared mine to the beta demo's UnityProgress.js file and they're identical. Below is the code for my UnityProgress.js.

Any ideas what could be causing this? I'm using Unity 5.3.2 for deployment (happened in 5.3.1 too), and I've seen the same result on Chrome/Firefox and Windows/Mac. My artist sees the same thing too, so it's not just on my end.

Thanks in advance!

Code (CSharp):

1. function UnityProgress (dom) {
2.     this.progress = 0.0;
3.     this.message = "";
4.     this.dom = dom;
5.  
6.     var parent = dom.parentNode;
7.  
8.     var background = document.createElement("div");
9.     background.style.background = "#2A2626";
10.     background.style.position = "absolute";
11.     parent.appendChild(background);
12.     this.background = background;
13.  
14.     var logoImage = document.createElement("img");
15.     logoImage.src = "TemplateData/boondogl_logo.png";
16.     logoImage.style.position = "absolute";
17.     parent.appendChild(logoImage);
18.     this.logoImage = logoImage;
19.  
20.     var progressFrame = document.createElement("img");
21.     progressFrame.src = "TemplateData/loadingbar.png";
22.     progressFrame.style.position = "absolute";
23.     parent.appendChild(progressFrame);
24.     this.progressFrame = progressFrame;
25.  
26.     var progressBar = document.createElement("img");
27.     progressBar.src = "TemplateData/fullbar.png";
28.     progressBar.style.position = "absolute";
29.     parent.appendChild(progressBar);
30.     this.progressBar = progressBar;
31.  
32.     var messageArea = document.createElement("p");
33.     messageArea.style.position = "absolute";
34.     parent.appendChild(messageArea);
35.     this.messageArea = messageArea;
36.  
37.  
38.     this.SetProgress = function (progress) {
39.         if (this.progress < progress)
40.             this.progress = progress;
41.         this.messageArea.style.display = "none";
42.         this.progressFrame.style.display = "inline";
43.         this.progressBar.style.display = "inline";          
44.         this.Update();
45.     }
46.  
47.     this.SetMessage = function (message) {
48.         this.message = message;
49.         this.background.style.display = "inline";
50.         this.logoImage.style.display = "inline";
51.         this.progressFrame.style.display = "none";
52.         this.progressBar.style.display = "none";          
53.         this.Update();
54.     }
55.  
56.     this.Clear = function() {
57.         this.background.style.display = "none";
58.         this.logoImage.style.display = "none";
59.         this.progressFrame.style.display = "none";
60.         this.progressBar.style.display = "none";
61.     }
62.  
63.     this.Update = function() {
64.         this.background.style.top = this.dom.offsetTop + 'px';
65.         this.background.style.left = this.dom.offsetLeft + 'px';
66.         this.background.style.width = this.dom.offsetWidth + 'px';
67.         this.background.style.height = this.dom.offsetHeight + 'px';
68.  
69.         var logoImg = new Image();
70.         logoImg.src = this.logoImage.src;
71.         var progressFrameImg = new Image();
72.         progressFrameImg.src = this.progressFrame.src;
73.  
74.         this.logoImage.style.top = this.dom.offsetTop + (this.dom.offsetHeight * 0.5 - logoImg.height * 0.5) + 'px';
75.         this.logoImage.style.left = this.dom.offsetLeft + (this.dom.offsetWidth * 0.5 - logoImg.width * 0.5) + 'px';
76.         this.logoImage.style.width = logoImg.width+'px';
77.         this.logoImage.style.height = logoImg.height+'px';
78.  
79.         this.progressFrame.style.top = this.dom.offsetTop + (this.dom.offsetHeight * 0.5 + logoImg.height * 0.5 + 20) + 'px';
80.         this.progressFrame.style.left = this.dom.offsetLeft + (this.dom.offsetWidth * 0.5 - progressFrameImg.width * 0.5) + 'px';
81.         this.progressFrame.width = progressFrameImg.width;
82.         this.progressFrame.height = progressFrameImg.height;
83.  
84.         this.progressBar.style.top = this.progressFrame.style.top;
85.         this.progressBar.style.left = this.progressFrame.style.left;
86.         this.progressBar.width = progressFrameImg.width * Math.min(this.progress, 1);
87.         this.progressBar.height = progressFrameImg.height;
88.  
89.         this.messageArea.style.top = this.progressFrame.style.top;
90.         this.messageArea.style.left = 0;
91.         this.messageArea.style.width = '100%';
92.         this.messageArea.style.textAlign = 'center';
93.         this.messageArea.innerHTML = this.message;
94.     }
95.  
96.     this.Update ();
97. }

 

Hear, hear!

I am experiencing similar issues. Sometimes it holds and then it is 'instantly' done.

Other times t takes an extrememly long time for the loading bar to be updated in the first place.
Looking at the default template it can take up to 10 secs. for the loading bar to show up in the first place.

Currently I do not feel confident about the entire loading process. It feels buggy to me and the end user.

It also strikes me as odd the the Angry Bots demo seems to load (and show progress) just fine.

Other threads (about progress bars and loading) have seen similar or related(?) issues. It would be great if we could get some feedback or anything on this?

 

Hi,

Maybe the problem is due to the server configuration. If the server don't provide the total file size to the client, the client can't display corectly the progress bar.

Try your project with Charles (or other HTTP proxy) https://www.charlesproxy.com/documentation/proxying/ssl-proxying/
Clear your browser cache and load your app. When your app is loading, check if you can see the total file size before the end, and check if Charles can display corectly the loading progress.

 

Sorry, I didn't get email updates for some reason. Good tip on the proxy though, that would certainly make sense as to why some of the Unity Beta demos still have working loading bars but some of us don't. Will get back to you once we try this. Thanks!

 

Did you get it to work? From other sites it appears to me like this is something Unity broke somewhere around 5.2.

edit - I'm having the same issue ... I think this might be related to the change to using gzipped files by default.

 

Same problem. It works fine in 5.1-.
Progress bar just jumps from 0.0 to 1.0 (Unity 5.2, 5.3, 5.4).

 

Hey, would you by chance have an example of a config file that works? I've got a config file for my server but I don't know how to set the gzip headers correctly.

 

I'm hosting it on azure using the app services.

 

I'm sorry to hijack an old thread, but I'm having the same problem with the progress bar not updating smoothly in 5.3 like it did in 5.1.

I'm using nginx instead of Apache, but the compressed files are being served as expected:
- the paths to the dataUrl, memUrl, and codeUrl values are directly to the *gz files
- the server is sending these files with the appropriate gzip encoding header
- the UnityLoader script is not complaining about having to do client side decompression
- the scene does work as expected once everything is loaded

I've put in console.log statements in various places within the progress script to try to see exactly when the bar is updated. From my observations it does not look like the progress bar or message is updated during file downloads at all. When the files start downloading it displays "Downloading 0.0/1", but this is never updated. Once the files are downloaded there are calls to SetProgress, but they all happen very quickly and my guess is that the main thread is so busy loading data into memory that the progress bar is not actually redrawn until everything is done. The result is that the progress bar is only visible for a brief moment just before the scene is ready.

What changed from 5.1 to cause this? How can we work around this problem? At the very least it would be useful for the progress bar to be updated as files are downloaded, especially for those with slower connections.

 

I'm pointing directly to the gz files because the files without gz appended do not exist, the url only works because of an apache rewrite rule. The browser asks for a file, the server sends it back. It is the data that is expected so unless I'm missing something, this would not change how the progress bar works would it?

 

I changed the paths back to .data, .mem, and .js (without the gz) as you instructed. The server is matching these and passing back the gz version along with the correct content-encoding header, and just as before the scene loads and works as intended.

However, the loading bar is again not working. I added more console.log statements to confirm my suspicions:

At the start of the script when the progress bar is created, the first message is "Downloading 0.0/1". SetProgress is never called during the download process, so the progress bar would not be doing anything during this time. Once downloads are complete, the message "All downloads complete" is very briefly displayed (along with progress being set to 0), and then "Preparing... 0/1" is displayed. SetMessage is called ~13 times but also SetProgress(0) is called. These all happen within 80ms so you don't even see this. After this, the .data file is loaded and a similar process happens, but this time SetProgress is called with values from 0 to ~0.93 and this all happens within about 50 ms, so the progress bar goes from 0 to 93% very fast - blink and you'll miss it. Finally, "Running..." is displayed via SetMessage and then after a second or so the scene is loaded.

In plain English, the progress bar does not update during download and when it does update, it happens very fast. This is in stark contrast to how it worked prior to 5.3.

 

Yes, I do have a working 5.1 build and for comparison's sake I put both on a brand new Ubuntu VM running Apache 2.4.18. I have the 5.1 version and a 5.3 version built. The only difference between the two progress scripts is that the 5.1 is slightly tweaked visually (colors, etc.) but nothing to do with loading. I also added console.log statements at the top of SetProgress and SetMessage for both versions so I can see when these methods are being called. Both are serving the compressed files via the .htaccess configuration, and in both cases the content-length and content-encoding headers are set.

After comparing these two, it has become more clear that the progress bar is mostly useful for the download portion of the loading process. In both versions, the "preparing" stages (post download) are a bit jumpy and the progress bar goes from 0 to 100 very quickly. The majority of the progress bar action happens during the download stage, and in fact in the 5.1 build the subsequent sections do not update the bar at all because there is a condition in SetProgress that doesn't allow progress to go backward, so once the download stage is at 100%, it's done.

However, in the 5.3 build SetProgress and SetMessage are not called at all during the download portion. Especially on a slower connection this results in a long period of time where the progress bar sits at zero. Then when the "preparing" and "running" stages are going, the progress bar jumps to 100 very quickly, and then a brief pause before the scene loads.

Is there a working example of the progress bar on a demo project where progress is updated as the files are downloaded? The progress bar is very important. When users wait 10+ seconds and nothing appears to be happening they will reload the page and start it over again...

Thanks for your time and attention on this issue!

 

These are the same conclusions we reached when upgrading to 5.3. One thing to keep in mind is that the asm.js compilation seems to lock up the thread which also halts any visual progress in the browser. The time it takes for this is very much project and hardware dependent.

FWIW we ended up faking a progress bar for downloads+compilation for a smoother experience but it still has the 'hiccup' during compilation.

 

That Angry Bots demo progress bar works like we would expect. One thing I noticed is that in your demo, there are calls to setStatus() that include the download progress, such as "Downloading... (x/y)". If you pause the debugger while the files are downloading you can see that this is some value like "12345/67890". However, in my build, this starts with "0.0/1" and never gets called again with any actual data size.

I also noticed that your demo server has Content-Type: text/plain and Vary: Accept-Encoding headers, so I added those just in case, but no change.

Our 5.3 build was made with 5.3.5f1.

 

Here's are the links:

5.1: http://45.55.177.28/dragster_5.1/
5.3: http://45.55.177.28/dragster_5.3/

 

Thank you for the detailed explanation, that all makes sense. I understand we're working with limitations of the browser, so hopefully things will improve going forward. In the meantime we'll see what we can do on our end to make sure users know to be patient while things are loading.

Thanks again for your time and attention!

 

Hi,

I recently updated to Unity 5.5... never had this problem before on our servers
(although one of our clients had it on theirs when we published using Unity 5.3 and was never able to resolve it).

However... publishing with Unity 5.5 now creates a similar issue (can't say if it's EXACTLY the same because the whole loading-animation process was changed in 5.5).

So what happens is basically this:
The screen simply stays light-gray for a long time. It doesn't even show the initial loading image... then after 20 seconds or so our loading image appears with the progress bar filled circa 12%... the loading bar doesn't ever move... the image stays for another 10 seconds before the animated "created with Unity" logo appears and flies towards us... after that it just stays light-gray for another 4-5 seconds before we finally arrive inside our actual project.

The very same server has always handled and still handles all builds from 5.3 and 5.4 perfectly in terms of loading!

Any idea what has happened there?
What was changed?

 

Okay I managed to fix my specific issue by adding a .htaccess-file to the Release-folder... I hadn't realized that this file is no longer provided by the build itself and has to be added manually.

 

Is there a way to optimise the size of the generated files ? Because currently my ".js" file is as large as my ".data" file, and I have not enable Data cache, so the result : the progress bar is stuck for a few seconds while loading the ".js" file. Is there a workaround ?

Thanks

 

I'm using 5.5.0f3 and there isn't a loading bar at all anymore... I have a client requesting this feature, is there any workaround for this bug?

 

Could it be this issue?:
https://forum.unity3d.com/threads/missing-progress-bar-in-5-6b1.446331/#post-2893447

 

@Matt_at_mindtrigger It could be however I'm using 5.5.0f3. I don't have any "your-build.json" file to edit that I can see. Is this something exclusive to the 5.6b?

 

Oh, you're right.

I don't know about 5.6b but I think in 5.5.0f3 the file is called UnityProgress.js and located in the TemplateData folder.

 

Oh ok!
I checked that file, could not find the line of code mentioned. Anyway what I did was simply changed the loading screen to a different color, and sure enough the loading bar was there, it was just not visible due to it being the same color as the background!

 

So, I too am struggling with the loading bar not appearing on my WebGL build (the unity icon does not appear either)

I am running this on a plain vanilla ubuntu server running apache2. I have double and triple checked that mod_rewrite and mod_mime are installed and running.

- I have included the .htaccess file in the Release folder. I get no messages regarding "you would get a speed up etc."
- I have tried modifying UnityProgress.js, hard coding the background color to white, also swapping out "Light" for "Dark" etc. The canvas color does change, but still no sign of icon or loading bar.
- I have disabled browser caching and confirmed that the assets (including UnityProgress.js) that I am seeing are indeed the latest uploaded to the server.
- I have made my build without data caching checked.
- I have also tried disabling gzip compression on the build.
- I have ensured that the data payload is substantial in size, and larger than the asm payload.

I'm out of ideas here! It really is pretty mission critical to give the user some kind of feedback -- even a minimal loader scene takes long enough to download that it may appear to the average user that the page is frozen.

 

The problem is that Chrome can not estimate download sizes on gzipped content.
Chrome 64 still has this issue (see https://bugs.chromium.org/p/chromium/issues/detail?id=463622 )

We have created a javascript library that fixes this issue and estimates the progress.
All you need to do is include it in your html page.

The javascript library can be found here:
https://github.com/AirConsole/xmlhttprequest-length-computable

 

Hello! This is happening for me with a Unity 2020 game. For the game files compressed with brotli, the progress jumps directly from 0.1 to 0.9 after a couple of seconds. I checked the request and the Content-length and Content-encoding is being passed correctly. If the game isn't compressed, the progress works very well.
The issue is present on Chrome and Safari, but works correctly on Firefox.

Request screenshot: (https://ibb.co/TBY9vZD)

 

Identical issue as pnkapadia6. Thanks for looking into it. Update: the library mentioned by n-dream back in 2018 provides a decent workaround (https://github.com/AirConsole/xmlhttprequest-length-computable).

 

Hi
I read through the readme and the example, however it is still not clear to me how to integrate this in the index file I get when I build my webgl build in Unity. Could you pleas give an example of usage for Unity Webgl build. Thanks.

 

Ok, got it, truce it was so simple I didn't try. As readme says, just add <script type="text/javascript" src="xmlhttprequest-length-computable.min.js"></script>

 

I've had this issue with a Brotli compressed build.

To solve it I used the above mentioned xmlhttprequest-length-computable solution:

1. Under my TemplateData I just created a file named xmlhttprequest-length-computable.min.js
2. Copy the minified js code from the repo and paste it in my xmlhttprequest-length-computable.min.js file. You can get the raw code here https://raw.githubusercontent.com/A...aster/xmlhttprequest-length-computable.min.js
3. In the index.html add the script tag to reference the local js lib:

<script type="text/javascript" src="TemplateData/xmlhttprequest-length-computable.min.js"></script>

​

Neat workaround

 

This workaround is working fine on the progress bar you see while the WebGL app is loading, but I need a solution for loading Asset Bundles: www = UnityWebRequestAssetBundle.GetAssetBundle
When I check www.downloadProgress on the update function, to increase my progress bar, it also jumps from 0 to 1, with no intermediate numbers, is there a way to solve this with a workaround?