Application.backgroundLoadingPriority

I’m trying to use Application.backgroundLoadingPriority
but It gives me an error .
I tried putting this line of code Application.backgroundLoadingPriority = ThreadPriority.Low; everywhere (In the start function , in the awake function , before using a asynchrony function ,after …)
The error I get :
res != 0
UnityEngine.Application:set_backgroundLoadingPriority(ThreadPriority)
UnityEngine.Application:set_backgroundLoadingPriority(ThreadPriority)
Thanks !

At least can someone give me a working example with Application.backgroundLoadingPriority
?

No one ? :cry:

I’ll run this by the development team. You should get a reply shortly.

I will be waiting . Thank you !

So Andeee did you get an answer from the development team ?

I’m getting this same error.

I also get it when I try to set the threadpriority for the WWW class.

I really need to be able to adjust these values because it’s effecting the performance of my game. Can anyone help please?

regards,

Tony Oakden

Hello,

Please can a developer answer this? Is there anyway currently to adjust the background priority for the loader and decompression in the www class? If not will there be a fix for this coming soon?

regards,

Tony

can you show code on how you do it in your Unity Pro 2.6?
does the code from the documentation ( Unity - Scripting API: WWW.threadPriority ) not work?

I am also getting the res != 0 error

The code I am using is:

IEnumerator getTexture(string fileName)
	{
		string file = "file" + fileName.Substring(1);
		WWW test = new WWW(file);
		test.threadPriority = ThreadPriority.Low;
		yield return test;
		
		Texture2D tex = null;
	        tex = test.texture;
		
		textureList.Add(tex);
	}

It works perfectly so long as I do not change the threadPriority.

Hello,

I have a suspicion that the error does not occur when the game is built as a web app and data is streamed from a http address. I think it only occurs when loading files directly or maybe when run as a standalone exe. I’ve not double checked this but things seem to work OK for me when I stream from the web from a web app. having said that I’ve come to the realization that the bottleneck, in terms of what I can stream, will be caused by the bandwidth of the connection that the average person will use. Decompressing the textures and reconstituting the model seems to be a relatively small cost even if I don’t mess with the default priority.

regards,

tony