openfl.display.Loader is significantly slower on native targets in Lime 8.2 (compared to Lime 8.1.3)

[joshtynjala]

The following code loads a lot of images simultaneously:

var images = ["image1.png", "image2.png", "image3.png"];

var xPos = 0;
var yPos = 0;
for (i in 0...40) {
	var loader = new Loader();
	loader.contentLoaderInfo.addEventListener(Event.COMPLETE, event -> {
		var loader = cast(event.currentTarget, LoaderInfo).loader;
		loader.width = 100;
		loader.height = 100;
	});
	loader.load(new URLRequest(images[i % images.length]));
	loader.x = xPos;
	loader.y = yPos;
	xPos += 100;
	if (xPos > stage.stageWidth) {
		xPos = 0;
		yPos += 100;
	}
	addChild(loader);
}

When I run it on a native target (neko, hl, cpp) with Lime 8.1.3, they all render basically instantaneously when the app starts up. With Lime 8.2, they seem to load one by one much more slowly.

I tried PR #1837, and it might help just a tiny bit. However, it is still clearly slower than Lime 8.1.3. Interestingly, in Lime 8.2, the images start rendering from last-to-first. With the PR, they render first-to-last.

[joshtynjala]

I found that I can make two changes to help.

In NativeHTTPRequest, I increased the max number of threads available to the pools:

localThreadPool = new ThreadPool(0, 50);

multiThreadPool = new ThreadPool(0, 50);

Additionally, I increased the max number of threads on FutureWork:

lime.app.Future.FutureWork.maxThreads = 50;

Increasing the maxThreads for both ThreadPool and FutureWork appear to be required to achieve the same instantaneous loads as Lime 8.1.3. Only one or the other is not enough.

For comparison, Adobe AIR appears to render the images basically immediately, like Lime 8.1.3.

I also forgot to mention that this slower loading behavior was first noticed by a user in one of their apps, and I'm reporting on their behalf.

[barisyild]

@joshtynjala @player-03 std::thread::hardware_concurrency can be good for maxThreads default value.

https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency