Why EndPresentationEntityCommandBufferSystem was deprecated?

What was the reason that we deprecated EndPresentationEntityCommandBufferSystem ? Is it because it has almost the same meaning and produce a sync point that cause minimal impact to jobs like BeginInitializationEntityCommandBufferSystem?

It maybe so for default world that is running by player loop when used fixed ECBS for that purpose because the next frame comes always, but only EndPresentationEntityCommandBufferSystem could make a manually updated default world complete with all expected results in a single run. (And also applies to easier testing an update on that world and check if the buffered tag/clean up commands works or not) If the command were scheduled against begin init wouldn’t it need an extra update to finally playback the changes?

Because of this I think we should to keep both, or maybe even deprecate the begin initialization one instead because that seems inferior or am I missing something?

Edit : I just realized that maybe using begin init would allow jobs to run far after even the last system in presentation group (still in PreLateUpdate) because the engine would force complete all jobs much later, so there are some performance difference after all.

 

Still interested in this.

 

I think this pretty much covers it @iamarugin, but I might be incorrect with how a system group actually synchronizes jobs. Ultimately I find myself preferring the

BeginInitializationEntityCommandBufferSystem

because it then makes it simpler to track down when certain changes happen.

Looking at the MonoBehaviour event functions order linked below, I've noted there's technically nothing happening between the Decommissioning and Initialization steps. This most likely gives jobs the last few cycles of the frame to still continue work before the next frame would synchronise their completion.

https://docs.unity3d.com/Manual/ExecutionOrder.html

 

Is BeginInitializationEntityCommandBufferSystem an alternative to EndPresentationEntityCommandBufferSystem? Maybe I'm overthinking the existence of the frame boundary.

I have an entity that a simulation system marks for destruction, but that a presentation system needs to process one last time. My plan is to queue the entity's destruction in BeginInitializationEntityCommandBufferSystem because EndPresentationEntityCommandBufferSystem doesn't exist.

 

That's precisely why

EndPresentationEntityCommandBufferSystem

has been removed. They both technically occupy the same point in time, but it was possible for someone to schedule other systems AFTER the

EndPresentationEntityCommandBufferSystem

which could further complicate the update loop's structure. As long as your system queueing the entity for destruction runs BEFORE the

BeginPresentationEntityCommandBufferSystem

the presentation system should be able to process the item one last time.

 

Thank you for confirming.

Your last sentence confuses me:

Why is

BeginPresentationEntityCommandBufferSystem

the cut off point instead of the presentation system of interest itself? (Assuming that the

DestroyEntity 

command is in a command buffer in the next frame (in

BeginInitializationEntityCommandBufferSystem

).)

 

I may have misunderstood your intention. I was under the impression you require the entity to be queued for deletion before the presentation system is run, but if it's not a requirement it can even run after the presentation system has run as long as it runs on the same frame that the presentation system last needs to do anything with the entity.

 

Wait a second, that's a good point! Thank you!