Run StatusBarProgressMeterEnd without RhinoApp().Wait(0);

Rhino Developer
1

I have a pool of computational tasks which run in async mode.
Each time a thread competes its task an atomic int is increased by 1.

After launching my threads I run this function to see the progress bar showing how many tasks have been completed.

bool updateProgressBar(ON_wString progressBarText, std::atomic<int>* barCurrentProgress, int totalWork)
{
	int pollingTime = 10;
	// initializing Rhino progress bar
	CRhinoDoc* doc = RhinoApp().ActiveDoc();
	doc->StatusBarProgressMeterStart(0, totalWork, progressBarText, true, true);
	doc->StatusBarProgressMeterPos(barCurrentProgress->load(), true);

	// start polling the jobs progress at a pollingTime(ms) rate
	for (;;)
	{
		int currentProgress = barCurrentProgress->load();
		RhinoApp().Wait(0);
		//doc->StatusBarProgressMeterPos(barCurrentProgress->load(), true);
		doc->StatusBarProgressMeterPos(currentProgress, true);
		// exit when all jobs have finished
		//if (barCurrentProgress->load() == totalWork)
		if (currentProgress == totalWork)
		{
			doc->StatusBarProgressMeterPos(totalWork, true);
			doc->StatusBarProgressMeterEnd();
			return true;
		}
		// wait some for some time before polling again
		std::this_thread::sleep_for(std::chrono::milliseconds(pollingTime));
	}
	return false;
}

It works well. However, when running a heavier set of tasks the progress bar was moving slower and I managed to notice that when all tasks are completed I get in if (currentProgress == totalWork) as expected, but the lines:

doc->StatusBarProgressMeterPos(totalWork, true);
doc->StatusBarProgressMeterEnd();|

are not executed. Setting a breakpoint I see that currentProgress == totalWork but the bar shows less and it does not disappear until the calling function exits.
I thought that this has to do with synchronization. So changed the code with:

			doc->StatusBarProgressMeterPos(totalWork, true);
			RhinoApp().Wait(0);
			doc->StatusBarProgressMeterEnd();
			RhinoApp().Wait(0);

Now it works, but I am wondering if this is a proper way to achieve this. Does RhinoApp().Wait(0); have impact on the performance?
Thanks!

2

While I do not know much about c++, I do know that in Rhino when doing async tasks, calling RhinoApp.Wait() gives the Rhino UI thread an opportunity to pump the messages to the UI to repaint the screen, etc.

So in my world I might do an Invoke to marshall the update of the UI to the UI thread. You are likely accomplishing something similar in your logic.

You can probably get away with just doing 1 of those calls after the StatusBarProgressMeterEnd(), rather than doing both calls to wait.

3

I have a rather old machine and after some testing I realize that even in a for loop (without async) when trying to show, update or end the progress bar I always have to add RhinoApp().Wait(0); to make the progress bar function properly.

4

Especially in a loop you need to give the UI time to update. So that isn’t necessarily something unique to your CPU speed. Anytime you want “UI” to be updated you have to all Rhino to pump messages to the UI, which is what RhinoApp.Wait() accomplished.

5

I have implemented the status progress bar at another part of the solution and I see that the line

doc->StatusBarProgressMeterEnd();

is only executed if I set the value 1 instead of 0

doc->StatusBarProgressMeterEnd();
RhinoApp().Wait(1);

Why is that? How the time argument in RhinoApp().Wait() has to do with the successful UI reaction? Is there proper value for this?

6

According the Rhino C++ SDK, that Wait() method takes a parameter in milliseconds, for how long it waits, and allows the UI Message Pump to work.

https://developer.rhino3d.com/api/cpp/class_c_rhino_app.html#ac72e8727a6c602f84862cc672b27e03c

So the more time you give it the more likely a UI event will update.

You should try experimenting and maybe start with 100, and go up if that isn’t enough to make it function. Remember 1000 is 1 second.

7

Hence, should I just try and test what is the minimum value that works? In this case could it be that an older machine requires more wait time than a new one?

8

I suspect it may need slightly more time on slower machines, however if going from 0 to 1 “fixed” it for you. You may be able to just set it to 100 ms and be fine.

No need to overcomplicate things.

Just bare in mind if you are in a loop the time will be a factor of the iterations through the loop…

1 Like