UI Toolkit runtime UI burst compatibility

[optimise]

Any plan and ETA to make runtime UI API to be able to support Burst compile so I can get the maximum performance for dots project? It means that currently UI Toolkit runtime UI is using class type and need a lot of rewrite and restructure to migrate to struct type to make it works.

[uDamian]

There’s no major rewrites of UI in the plans, no. VisualElements are here to stay. We’ve actually attempted a struct-based Burst-compatible UI framework a few times but in the end, we are still aiming with UI Toolkit to get to a single UI framework for all use cases. This means we cannot have a different UI framework just for Burst/DOTS.

That said, we are doing a lot of work under the hood to make UI Toolkit itself faster. We’ve started and will continue to move more and more of the core framework to C++. This work, by necessity, will involve moving more and more of VisualElement’s own internal state to a struct to make it easily accessible on both the native and managed sides. This will likely open up limited support for data oriented UI management.

[optimise]

@uDamian

There’s no major rewrites of UI in the plans, no. VisualElements are here to stay. We’ve actually attempted a struct-based Burst-compatible UI framework a few times but in the end, we are still aiming with UI Toolkit to get to a single UI framework for all use cases. This means we cannot have a different UI framework just for Burst/DOTS.

That said, we are doing a lot of work under the hood to make UI Toolkit itself faster. We’ve started and will continue to move more and more of the core framework to C++. This work, by necessity, will involve moving more and more of VisualElement’s own internal state to a struct to make it easily accessible on both the native and managed sides. This will likely open up limited support for data oriented UI management.

Do u mean in future we can get something like burst compatible VisualElements that able to put into burst system? I dun expect full dots runtime UI that written in ECS fashion. I just want it to be able to put into burst system.

[uDamian]

@optimise

Do u mean in future we can get something like burst compatible VisualElements that able to put into burst system?

Not the entire VisualElement itself, but rather it’s “state” object. So you wouldn’t be able to process the entire hierarchy of VisualElements inside a Bursted function, but you might be able to process an array of VisualElement “states”. This is still rather far out though so a lot can change.

[optimise]

@uDamian

Not the entire VisualElement itself, but rather it’s “state” object. So you wouldn’t be able to process the entire hierarchy of VisualElements inside a Bursted function, but you might be able to process an array of VisualElement “states”. This is still rather far out though so a lot can change.

I see. As long as provide a path that at bursted system I able feed ECS data to ui toolkit runtime ui to update ui should be ok that I won’t be forced to use non-bursted system that will decrease the performance a lot because of there’s no burst compatible path.

[uDamian]

@optimise

I see. As long as provide a path that at bursted system I able feed ECS data to ui toolkit runtime ui to update ui should be ok that I won’t be forced to use non-bursted system that will decrease the performance a lot because of there’s no burst compatible path.

Yep. We’re definitely going to keep this use case in mind.

[optimise]

@uDamian

Yep. We’re definitely going to keep this use case in mind.

Hi. I would like to know which Unity version will enable this feature?

[uDamian]

@optimise

Hi. I would like to know which Unity version will enable this feature?

This isn’t so much a feature we will ship in a certain version of Unity. It’s more a workflow that we will strive to support and account for as we iterate on the UI framework.

This will be gradual. As we optimize the internal data layout and compute of UI Toolkit, we’ll expose more direct ways to input/output pure data into/out of the UI state in a data oriented way. But to be clear, this will not necessarily mean VisualElements will become Entities or something that direct. I’m only talking about the API interface gaining more pure data oriented entry points for performance sensitive applications.

You may start seeing some of this work towards the end of 2023, but it’s too early still to talk about exact APIs and dates.

[optimise]

@uDamian

This isn’t so much a feature we will ship in a certain version of Unity. It’s more a workflow that we will strive to support and account for as we iterate on the UI framework.

This will be gradual. As we optimize the internal data layout and compute of UI Toolkit, we’ll expose more direct ways to input/output pure data into/out of the UI state in a data oriented way. But to be clear, this will not necessarily mean VisualElements will become Entities or something that direct. I’m only talking about the API interface gaining more pure data oriented entry points for performance sensitive applications.

You may start seeing some of this work towards the end of 2023, but it’s too early still to talk about exact APIs and dates.

Ya understand. I just want the APIs to be burst and job compatible. Even better if official can make UI Toolkit editor APIs to be burst and job compatible too. Recently I realized that editor APIs also really need this to write super complex editor tooling.