View Issue Details
ID | Project | Category | Date Submitted | Last Update | |
---|---|---|---|---|---|
0019151 | AI War 2 | Bug - Other | Jun 2, 2017 9:35 pm | Jun 5, 2017 1:42 pm | |
Reporter | Chris_McElligottPark | Assigned To | Chris_McElligottPark | ||
Status | resolved | Resolution | fixed | ||
Product Version | 0.400 Usability and the GUI Pipeline | ||||
Fixed in Version | 0.400 Usability and the GUI Pipeline | ||||
Summary | 0019151: ActuallyDestroyButtonsThatAreStillClearedExpensiveAndGCAlloc investigation. | ||||
Description | This method is something that incurs a pretty heavy cost if done frequently, and is one of the biggest costs in the GUI at the moment if it's called more than just when a menu gets opened or whatnot. If it's when a menu is opened or shut, the cost is so negligible and this issue can probably just be closed. If it's something that is ever happening routinely when data is updated, then it would be responsible for spikes. Ideally this would instead call SetActiveIfNeeded( false ) on the elements that are to be "destroyed," and then set them aside in another buffer and ignore them. Ideally not changing their transform.parent, since that's costly, and simply ignoring them for all layout purposes instead. Then when new buttons or whatnot are needed, pulling from here first before creating new entries, and simply turning these back on and adding them back to the main Buttons list. TLDR it depends on the use case. Opening/closing a menu is so negligible it may as well just delete them. Something more frequent... well it depends on how frequent, and how big these lists of buttons are. | ||||
Tags | No tags attached. | ||||
|
I investigated, and using SetActiveIfNeeded(false) instead of DestroyMeExpensive() results in the "extra" buttons remaining behind, just without text. That doesn't fit with what enabled=false is supposed to mean, so I dunno. So I left this in the code for you: //CHRIS_TODO: comment out the next two lines, and uncomment the two lines after that, and then change/replace them so that going between the build menu's tabs doesn't result in a bunch of extra blank buttons when you go back to the I-IV tab To test: 1) Start new game 2) Press 1 to select Ark 3) Press 3 to open build menu 4) It starts on the I-IV tab; click through each of the others and then back to that one 5) Observe some leftover blank buttons (some of which actually overlap buttons-in-use on the I-IV tab). |
|
Finished fixing it, and renamed it to ActuallyPutItemsBackInPoolThatAreStillCleared. Teamwork! :) |
Date Modified | Username | Field | Change |
---|---|---|---|
Jun 2, 2017 9:35 pm | Chris_McElligottPark | New Issue | |
Jun 2, 2017 9:35 pm | Chris_McElligottPark | Status | new => assigned |
Jun 2, 2017 9:35 pm | Chris_McElligottPark | Assigned To | => keith.lamothe |
Jun 3, 2017 5:44 pm | keith.lamothe | Assigned To | keith.lamothe => Chris_McElligottPark |
Jun 3, 2017 5:47 pm | keith.lamothe | Note Added: 0046257 | |
Jun 5, 2017 1:42 pm | Chris_McElligottPark | Note Added: 0046260 | |
Jun 5, 2017 1:42 pm | Chris_McElligottPark | Status | assigned => resolved |
Jun 5, 2017 1:42 pm | Chris_McElligottPark | Fixed in Version | => 0.400 Usability and the GUI Pipeline |
Jun 5, 2017 1:42 pm | Chris_McElligottPark | Resolution | open => fixed |