Unfortunately, this performance improvement is expected to impact selection and deselection times specifically. The use case of interacting with studio while having a large amount of selections, and the lag resulting from that, is expected to be affected but not as drastically.
As @Dogekidd2012 mentioned, the Selection Highlighting beta does come with a meaningful rendering efficiency improvement, which should help with the testing case mentioned above to some degree.
We do recognize interactions with a large number of selections is a pain point for developers. Even if these issues haven’t been completely resolved with the update, we will continue working to make Studio a better experience.
I’ve been using the beta when I first wrote all those points down.
Right now ive tried comparing relatively quickly the differences between having the beta enabled and disabled, and this is what ive got: (BTW all values are from selecting a single folder that holds the specified amounts of parts below in the same baseplate)
3.5~ FPS with 100k parts with the beta disabled
23~ FPS with 10k parts with the beta disabled
120+~ FPS with 1k parts with the beta disabled
3.8-4.2~ FPS with 100k parts with the beta enabled
32~ FPS with 10k parts with the beta enabled
130+~ FPS with 1k parts with the beta enabled
I appreciate this rendering optimization however it looks like its differences are not exactly that meaningful on both far end sides of the spectrums. It mainly offers a noticeable differences right in the middle (and i think that’s better than only having effects on the far ends) however at the end of the day it’s kinda still not a very large improvement especially considering that all it does (at least from what i’ve seen) is just remove the physical bounding boxes from large part selections.
Thank you roblox, your really pushing out loads of QOL updates at the moment and they are very much appreciated!
May I ask, Does this update make Grouping/Ungrouping models faster? They have always been extremely slow!
Very intriguing! I’ll see if I can take some time out of my day to reproduce this and figure out what the cause is. My suspicion is it could still be rendering issues, which is a bit out of my ballpark, but would be great to at least know why.
Edit: Ah yeah, I’m able to reproduce. Looks like rendering woes. We’ll get a ticket internally for it.
It shouldn’t, but we’re looking into that too as a pain point. We’re having some issues reproducing at the moment, does this happen every time? Like if you ungroup then group the same parts, it’s still slow? Does this also happen when you group as a folder?
One issue that may be causing performance issues when ungrouping groups is that SelectionChanged is fired x amount of times for x number of instances in the group. For example, ungrouping a group of 800 parts will fire the event 800 times. This can be detrimental to any built-in or developer-made plugins that listen to SelectionChanged. As a developer, I would expect SelectionChanged to fire once with every instance selected that was just grouped together.
Years ago I filed a bug report on it, but it was never followed up on. It appears that the issue was partially fixed as SelectionChanged now only fires once when grouping a model. However, the issue still persists when ungrouping models and can be reproduced in the latest version of Studio.
Great find–this is definitely a good lead to follow, a lot of the work done to optimize drag select was minimizing the impact of an individual SelectionChanged.
Have you also tried fixing trying to change sound properties? For me, even when the sound is not playing, changing sound properties is very laggy for some reason. It’s worse when the game is running from what I remember.
Thanks for this update though!
This is excellent, I can really feel how significant the speed up is on my machine, and I’m very happy about it! I can now select thousands upon thousands of parts at once, and I don’t even feel any bump at all anymore.
Thank you so much! I appreciate this being looked into as it can be a serious drain on performance when ungrouping models for any plugins listening to SelectionChanged.
(Trying to drag multiple parts unexpectedly stops moving the parts. Releasing the mouse button and selecting the parts again drags the parts as expected but with an offset from the last drag that broke.)
I’ve been able to recreate this very consistently with a selection of multiple parts (2, 3, 4, 8, etc). I can not reproduce it with a single part. (Edit: In Zomebody’s video this also happens with a single part.)
The multi-part drag seems to break specifically when the mouse is moved quickly. It seems to have the potential to break per drag: some drags can break and some drags will never break no matter how fast or wildly the mouse moves (doesn’t depend on selected parts).
I am experiencing the same bug as well (on Windows). I have a heavy suspicion it is tied to this update, as it started happening within the last 24 hours for me.
In my case I also consistently observe the bug with one object selected (see video below). As demonstrated in the video, the dragged object randomly loses focus if you start dragging it shortly after copying and selecting it. I am still holding my mouse button down as soon as it loses focus. The dragging handles also seem to be misaligned, which may be a helpful indicator when looking into this issue.
cc @DeFactoCepti since you mention selection and deselection times being slower, this video may be of interest to you. It seems something in the new selection logic may be interrupting the ability to drag the object. It legitimately takes me twice as long to get any (building) work done while this bug is present. If this bug is related to this feature, please consider reverting the update until the issue is fixed.
I am very grateful for this update, you guys have really been doing an awesome work in 2023. The performance got on my nerves at times, but it seems to be smooth now. Thank you very much, this makes studio more fun to use when working with large scale projects.
