We don’t have a timeline in mind yet, but have an intent to transition GameObject to be more lightweight, after which point a change in the allocation of instances might be possible.
For MonoBehaviour derived classes we don’t have any plans to change their allocation. The intent is for performance sensitive use cases to use IComponentData based chunk storage for data.
I don’t understand how these 2 are correlated? Could you please explain it a bit more?
Because when ECS for all will be available in 6.7 GameObject and Entities will coexist.
I know about ECS for All, but still I don’t get what jivalenzuela meant.
I could be wrong so my apologies.
For the IComponentData thing I think he means changing the layout of the allocation data in memory allowing to set the positioning of certain more commonly used values to make them faster to access in memory and to also prevent wasting memory allocation requsts for the CPU.
Example people currently use the StructLayoutAttribute to control how certain objects are laid out in physical memory. Using this you can optimize memory reading by putting commonly read together values closer in thje memory layout lowering the time going back and forth to access data.
In ECS you can define a ComponentType like Buffer and Chunk components. With Chunk components you can make it where you only need to access a certain chunk of memory instead of trying to start from the starting address of an object in memory lowering the amount of physical memory locations you have to go back and forth through. Also they act as unmanaged memory types so you can do a lot of burst and jobifcation for certain data reading for higher performance…like multithread memory allocating mentioned in the post.
Edit: Sorry forgot to post the link to the multithread memory allocation announcement.
CoreCLR, Scripting, and Serialization Update - June 2026 - Unity Engine - Unity Discussions
Documentation Link:
Chunk components introduction | Entities | 6.5.0
I’m pretty much familiar with how ECS works. I’m working with ECS daily after all. But I still don’t get the correlation in his message.
Thx for clarification 
Included your comment into the video:
The reason it might be good to change the memory layout for MonoBehaviours would be to improve performance of accessing data in them, but we’re saying: if you want improved performance for data stored in MonoBehaviours, you should migrate that data to IComponentData instead.
I was thinking that a lot of times I need to reference objects in someway and usually I came up with dummy MonoBehaviours used just as Tags but without using real “Tags”.
Using ECS I can just put a tag IComponentData (now I don’t remember exactly the name) to mark the entity, with ECS for all it would be interesting for me to use these IComponentData instead of placing dummy MonoBehaviours which are “heavy”.
And then I ask myself, if Entities and GameObject are unified now, we aren’t tags already just an IComponentData?
Honestly I would expect the move for common things like that to be put into IComponentData or some form of Handle struct. Example the Unity 6.3 introduced TransformHandle API to allow burst and easy IJob code for transforms of an object.
I know some of the 2DPhysics stuff also just got a handle last week.
Unity - Scripting API: PhysicsHandle
It would be nice to see more of that.
Please add this version to the build automation.
Thanks in advance.
Renaming of “UI Document” component is really good.
It was just little confusing.
“UI Document” should mean UXML document.
So “Panel Renderer” is more intuitive and directly in the context.
Are you guys planning on making a separate window for uGUI? I find it annoying to transition between 2D and 3D and refocus my scene camera.
Can’t you just open a second Scene window?
Didn’t think of that 
Although, I still think that a separate window similar to the UI Toolkit would make it a lot easier to work with uGUI.
A late message, but Horaayyy! Actual good update for the engine, and one more step towards HDRP removal?
Where I can find the documentation for the sprite blendshape workflow?
I’m looing at Sprite Editor in 6.5 and see nothing.
Same. Something about 6.5 broke the rendering and cameras of my Android project. Reverting back to 6.4 now.
@JosephTakayama Here you go a small rundown.
Look into the Sprite related GraphicBuffer stuff instead of the Sprite Editor.
Basically you are working on the BlendShapeBufferLayout instead.
Link goes to manual page showcasing an example of BlendShapeBuffer usage.
Unity - Scripting API: Mesh.GetBlendShapeBuffer
The BlendShapeBufferLayout isn’t just for Sprites, but any mesh.
Hint the Mesh.GetBlendShapeBuffer method. The Sprite.GetBlendShapeBuffer method literally calls into the base Mesh.GetBlendShapeBuffer if I remember correctly. The API lets you grab the GraphicsBuffer with the blend data per shape from the mesh.
This allows writing data for Sprite vertices directly to the GPU.
The GPU takes in your BlendShape data and uses it to manipulate the vertexes of the sprite which acts like a deform of the sprite mesh.
You have two BlendShapeBuffers you can choose from for sprites as of 6.5.
you can do it on a per shape or a per vertex buffer. See Rendering.BlendShapeBufferLayout.PerShape and Rendering.BlendShapeBufferLayout.PerVertex for what you can do per buffer.
When you do data changes to these buffers Unity uses a Compute shader to change them. This means Compute Shader support is required when doing this.
Note the returned buffer needs disposed manually after use or you will get a memory leak.
Unity - Scripting API: BlendShapeBufferLayout
The Sprite API has added a few new methods to deal with BlendFrames and BlendShapes.
Unity - Scripting API: Sprite.GetBlendShapeBuffer
Edit: Adding some information on requirements.
Note in Unity 6.6 there is a change in workflow for UI Toolkit. There is the new UI Viewport which is a huge upgrade to the UI BUilder in so many ways.
Multi selection, huge highlighting improvements for the UXML/USS preview panels, better stylesheet/ui library window, they can be dragged as seperate tabs allowing you to change the layout of the ui viewport however you want, and way smoother creation workflow. The performance different between the UI Builder and UI Viewport is stupidly huge.
Edit: The UI Viewport basically acts like editing a prefab in isolation mode. You literally edit the UI Elements using the normal scene heiarachy and component inspector now. Note it is alpha 7 and they are adding more for upcoming alphas to improve it even more.
