2.19 Render::restoreState takes way too much time

[Amerio.Stephane]

Hello,

I use Render::saveState() and Render::restoreState() to have per-viewport specific render settings. But Render::restoreState() takes around 11ms !!! This effectively makes it impossible to use for any real-time task.

The objective is to have for each viewtype some specific adjustments for each type of sensor, which are not solved by a post-process material, and still keep these adjustments out of hard-coded Render::set* functions in the source.

Here is how I use it:

BlobPtr render_states[8]; // each view type gets its own render settings

int SystemLogic::init() {
  ...
  	render_states[0] = Blob::create(); // state 0 is the default and shall always exists
	Render::saveState(render_states[0]);
	for (int i = 0; i <= 7; ++i) { // one for each CIGI view type
		String render_settings = String::format("viewtype_%d.render", i);
		Log::message("Loading Render settings %s\n", render_settings.get());
		if (Render::loadSettings(render_settings)) {
			render_states[i] = Blob::create();
			Render::saveState(render_states[i]);
		}
	}
  ...
}

 

// For each viewport window						
window->getEventFuncBeginRender().connectUnsafe([this, viewportId]() { beginRender(viewportId); });
window->getEventFuncEndRender().connectUnsafe([this, viewportId]() { endRender(viewportId); });

 

void SystemLogic::beginRender(int viewportId)
{
    // retrieve the viewtype ID from the viewport ID (can be changed dynamically)
	int viewId = viewport_view.value(viewportId, ig->getCurrentView());
	if (auto view = ig->getView(viewId)) {
		int viewtype = view->getViewType();
		applyRenderState(viewtype);
    }
 }

 

void SystemLogic::applyRenderState(int viewtype)
{
	if (0 <= viewtype && viewtype < 8 && render_states[viewtype]) {
		render_states[viewtype]->seekSet(0);
		UNIGINE_PROFILER_SCOPED("restoreState");
		Render::restoreState(render_states[viewtype]); // TAKES MORE THAN 11ms!
	}
}

[silent]

Hi Stephane,

Yes, restoreState is quite heavy operation to perform it each frame (in our tests, however, we have numbers about 5-6ms).

For that case the only possible solution is to keep changed parameters separately and apply / restore only them manually avoiding the heavy restoreState usage.

Thanks!

 

[Amerio.Stephane]

So this means we're stuck with hard-coded (or some kind of) state switching...

Anyway, is there some kind of light weight render-state push/pop mechanism? 

Note: the doc would benefit from some hint of which function are really costly and discouraged to be called every frame.

[silent]

I'm afraid, there is no lightweight analogue, only manual hard-coded handling of required parameters.

Quote

Note: the doc would benefit from some hint of which function are really costly and discouraged to be called every frame.

That's indeed a very nice addition, but it may be difficult to achieve. For some small projects, spending 5 milliseconds on preset switching might be acceptable drawback. We will explore ways to enhance the documentation regarding this matter, thanks for the idea!