Optimize DLabel autostretch behavior

[thecraftianman]

Currently, DLabels will constantly try to perform their vertical autostretch behavior on Think, which has a notable performance impact when many panels derived from it are present on screen (such as in a DListView). This PR simply moves this behavior into PerformLayout, forcing these panels to attempt autostretch only when they may actually need to do so.

This also modifies Panel:SizeToContentsY and Panel:SizeToContentsX behavior to cache their last respective contents sizes used in order to avoid constant PerformLayout loops.

Autostretch logic before (measured over 20 seconds):

Autostretch logic after (measured over the same time period):

[robotboy655]

Do these checks actually do anything? They are also performed on the C side.

[thecraftianman]

I originally added those checks to avoid constant PerformLayouts with certain DLabel panels that have autostretch enabled and thought that I could remove the variable to make the changes a bit simpler, but it seems like this change causes the same issue whereas using a variable for caching does not.

Here's an example that I'm using to test this behavior with vgui_visualizelayout 1:

    local testFrame = vgui.Create("DFrame")
    testFrame:SetSize(400, 400)
    testFrame:SetDeleteOnClose(true)
    local testLabel = vgui.Create("DLabel", testFrame)
    testLabel:Dock(FILL)
    testLabel:SetText("test")
    testLabel:SetAutoStretchVertical(true)

[robotboy655]

Wouldn't the proposed changes just make the function not work if the label's size gets changing by whatever means?

For example:

local testFrame = vgui.Create("DFrame")
testFrame:SetSize(400, 400)
testFrame:SetDeleteOnClose(true)
testFrame:MakePopup()

local testLabel = vgui.Create("DLabel", testFrame)
testLabel:Dock(FILL)
testLabel:SetText("test")
print( "Size 1: ", testLabel:GetTall())
testLabel:SizeToContentsY()
print( "Size 2: ", testLabel:GetTall())
testLabel:SetTall( 60 )
print( "Size 3: ", testLabel:GetTall())
testLabel:SizeToContentsY()
print( "Size 4: ", testLabel:GetTall()) -- Not sized to contents!

[thecraftianman]

Alright, I believe I've come up with a solution that should both avoid the broken resizing you've shown and prevent any potential infinite layout loops in 1648df2.

[robotboy655]

I have tested the new code, it works better, but it does introduce difference in behavior.

I am not sure what's the preferred outcome is with Dock( FILL )ing a self-sizing panel is, it is kind of a paradox.

But you mention that this was originally aimed at fixing performance issues with DListView, can you provide an example where this issue can be observed?

[thecraftianman]

The behavior change with Dock(FILL) was intentional; I wasn't really sure what the intended outcome should be either because the current behavior just formats the panel in the same way as Dock(LEFT), so I just tried to go with the one that doesn't get stuck infinitely refreshing the panel. If you'd prefer the behavior to stay the same, though, I'm happy to make that change for you. I need to make one more tweak to this PR anyways because I've found an issue with another panel in the meantime.

For an example with a slow DListView, just run FProfiler in Client mode. All of the DLabel Thinks in its own DListView will consistently be one of the top bottlenecks.

[thecraftianman]

This latest commit should both prevent any infinite layouts with affected Dock types and avoid any visual changes to existing panels, as shown here:

[robotboy655]

I am not sure I like the fact that you are disabling the Dock on the panel from the panel itself.

It may work for your example and I can understand what you are trying to do here, but I am afraid it may cause issues when people are doing things like re-parenting the panel, and expecting the dock state to persist.

I don't think there's a way to preserve existing behavior while making it be not called as many times.

I think the best approach would be to just don't set the height for certain dock types, without resetting the docktype. This has potential to break existing addons still, due to the change in visual behavior, but this alignment issue should be solved via Panel:SetContentAlignment, not by relying on weird behavior like this.