Issue with View Driven Cell Sizes demo

[thomassavysoda]

Hi,

Noticed an issue when using the View Driven Cell Sizes as defined in the Demo 8. We followed the demo with our own logic but recently have been facing an issue where the enhanced scroller is creating too many cells when it initialised which causes a bunch of cells to be instantly recycled. From what I can tell it's loading the entire data set at once (Essentially no longer data driven). As I thought this might be something wrong with our logic we ran the Demo 8 and found that this demo also has this issue. Currently this issue is causing performance issues due to the unnecessary extra loading of cells.

Any help with this would be so greatly appreciated.

Thanks!
Thomas

Unity Version: 2019.4.10f1
Enhanced Scroller Version: 2.26.0

[echo17]

Hmmm, that is interesting. So the way that the Demo #8 works is that it has to generate all the cells so that Unity can calculate the dimensions of the cells. You can see in the CellView for that demo that the function

Canvas.ForceUpdateCanvases();

is being called. This tells Unity to do its layout calculations. Once that is done, the newly formatted cell can be use in storing the height inside the data.

Unfortunately, it has the side effect of needing all cell views to be generated once. Only the visible cells are active at any given moment after this initial generation, however.

Demo #8 is one way to do view driven calculations. Another way would be to try to calculate the size yourself, based on whatever your cell contents are. This way you can set the height in the data, and then pass that height in the controller's GetCellViewSize method. How you do this calculation will depend on what your cell contents are:

1) If they are just an image, you can use the image's size.
2) If they are text and you know the font size, you could calculate the space needed for the text by performing a loop over the characters, incrementing the size as new lines are encountered. This is pretty tricky and is what Unity actually does in the Canvas.ForceUpdateCanvases(); code, which is why I chose to use that instead.

I'll need to think on this a bit to see if I can provide a nice generic example that is an alternative to Unity's Canvas.ForceUpdateCanvases(). Canvas.ForceUpdateCanvases() handles all UI elements, so it is pretty powerful. In the meantime, you might be able to implement one of the above processes that fits your project.