Whats a roblox/selection, this has peaked my curiousity. Still want drag-drop support from the external file system in plugin GUIs. (ie dragging an RBXM from Explorer into Studio).
Now would be a great time to request this since plugingui drag drop seems to be getting some love again.
Performance improvement for ‘:IsA()’!?
How?
Isn’t that just a simple check for the type? How does that have any noticeable impact on performance. And more importantly: how did you make it faster? 
A mime type representing that the current DataModel’s Selection is the thing being dragged, which various pieces of Studio like the new Explorer will follow as a convention.
You can’t send Instance references through a system-level Drag-n-Drop so an alternative mechanism is needed to communicate dragging of the selection.
Are there any decent performance uplifts from this? I’m curious to know exactly how much this property increases performance!
What does this property do? Can’t find any information on it
That’s all the info. Still no clue about what it actually changes performance wise.
excited for this
While this isn’t an official answer, it’s important to recognize that in coding, there are often numerous ways to reach a solution, and many can be optimized significantly using techniques like caching, divide-and-conquer, dynamic programming, memoization, and even parallel processing in some cases.
For instance, various search algorithms—like linear search, binary search, and hash-based search—perform differently based on the structure and size of the input. Each algorithm has strengths suited to particular types of data, and choosing the right one can make a major difference in efficiency.
In short, runtime optimization is essential for effective code, and understanding concepts like Big O notation, amortized analysis, and space-time trade-offs can help you make well-informed decisions about the best approach for any given problem.
My guess is InvalidatedFastClusters, basically, from my understanding, there is some precalculation/cached stuff to models containing a humanoid, to make their rendering faster. However, updating things inside the humanoid causes it to recalculate stuff, leading to lag spikes (or general lag) when doing frequent visual updates to characters
Would be nice if an engineer could confirm, or tell what RenderingCacheOptimizations is for
Adds “Occlusion Culling” as a Studio beta feature. [Pending]
W update, excited to test performance differences!
What you’re thinking of is our internal IsA being O(1), but that’s because we already know the classes and such in advance at compile time. The Luau method wasn’t quite so brilliant. The optimization was a pretty straight forward one: we’re caching the class that a string of its name correlates to directly. This allows us to actually use that clever O(1) optimization that we weren’t before.
Makes AssetService:CreateEdtiableMeshFromPartAsync() non-functional; switch to AssetService:CreateEdtiableMeshAsync().
This has a slight spelling error, CreateEdtiable should be CreateEditable.
What use case do you want the previous behavior for?
Sky has been implemented for viewports since the beginning I think, but it’s not used for skyboxes, it’s used as a cubemap to give reflections to reflective objects in the viewport frame.
They were implemented not too long ago, before then it was just ambient and a sun.
After I updated studio and my in-game servers updated I noticed that after the most recent update, it can completely break movement with characters that rely on forces like LinearVelocities when the HumanoidRootPart Massless property is set to true.
(Even without those forces, when the rootpart is massless it causes some very weird physics when animations are played on the humanoid.)
I fixed it by simply disabling the massless property, but if you don’t revert it at least list these changes in the release notes!! Anytime a game breaking physics bug happens from a Roblox update it’s NEVER listed as a real change. And I always have to go digging and testing to try and fix it. I’m lucky this one took me only around 10 minutes of stress, last time this happened I was searching for hours.
RE the first one:
This is a more comprehensive optimization for IsA, FindFirstChildWhichIsA, FindFirstChildOfClass, FindFirstAncestorOfClass, and FindFirstAncestorWhichIsA, and a few other internal systems (e.g. we get a little better startup times in networking code).
We added a few fast class lookup structures, which allowed other engine systems to integrate more tightly with Instance reflection in perf-sensitive areas. This allowed faster IsA checks as @Dogekidd2012 mentioned (optimizes IsA, FindFirstChildWhichIsA, FindFirstAncestorWhichIsA), and also unlocked direct comparison between class types (optimizes FindFirstChildOfClass, FindFirstAncestorOfClass).
Speedups were in this general ballpark for big Instance trees:
FindFirstChildWhichIsA was an outlier because it had a few other missing optimizations.
