Issues upgrading to v3.5.4 from 3.4.8...

[QuantumMechanic]

Friday we upgraded from 3.4.8 (with the trim change that was posted in the forums to reduced memory) to 3.5.4.  We were hoping that the note below would result in less memory use.

3.5.4
- NEW: Cached buffers are now per-draw call rather than global, reducing memory allocations.

However, our experience is that when comparing 3.5.4 with 3.4.8 on the same code base, our memory allocations has increased by a couple of megabytes.  Is there something else that was added that might explain this? 

Looking over the changes, I am not sure how moving the verts, norms, uvs and tans from static lists in UIPanel to instance based lists in UIDrawCall is beneficial.  It would seem to be that under the old system, if I had a panel with three draw calls -- one with 1000 verts, one with 500 verts and one with 250 verts -- I would have one allocation for 1000 verts.  Under the new system each draw call would have their own allocation and thus I would allocate memory for 1750 verts.  There is probably something subtle I am not understanding here.

Also there is a comment in the change log for 3.5.2

 DEL: Removed UICamera's OnInput event as it wasn't being used (as it wasn't reliable).

We were using the OnInput event to enable and disable buttons based on when the entry in the input box was valid.  Since we have multiple input boxes on our screen, we would catch the event -- ignore the parameters and check all the input boxes on screen to see if we could enable to submit button (was it the parameters that were unreliable?).  What would be the correct way to structure something like that now that OnInput has been removed?

[ArenMook]

Instead of using OnInput, just do your Input.Get checks in Update() yourself. UIKeyBinding does this, for example.

The per-draw call cached buffers come into play when you have two panels that are changing their content. For example one with 1000 vertices and another with only 10. Before, since the buffers were shared, the 1000 vertex panel would cause the cached buffer to have enough space for all 1000 vertices, allocating the necessary memory. Then the next panel would update, and it would have to trim the content because 99% of the memory is not needed, resulting in GC. Next frame the first panel would again allocate 1000 vertices, and the second panel would again trim it. This is obviously very bad for performance.

Current approach ensures that the GC doesn't happen unless it's actually needed.

[QuantumMechanic]

Thanks for you answers.  I wasn't aware that BetterLists ToArray() was calling Trim() -- but I understand why it needs to and that explains the new treatment of draw calls.  This optimization reduces the number of allocations not the amount of memory allocated and gives us better performance.

I will code the Update loop as you suggested.

Any thoughts beyond the DrawBuffer arrays as to why memory might have increased between the two versions of the library?

[ArenMook]

Less memory trimming, perhaps. You can try it by finding line 406 of UIDrawCall and forcing 'trim' to be 'true'.