Question How to make a performant GridView

Hi!

There is currently no gridview component.

But there is a listView that could help you with performance as it does not display what is not shown.

This user recently went in that direction to display thousands of images: https://forum.unity.com/threads/hit...ews-custom-asset-loader.1095310/#post-7103815


You should still be able to modify more than 350 elements: can you do a capture with the profiler and share it so that we can see what takes the performance down? There may be something that could be changed quickly.

 

Thanks for sharing more details on your specific usage.

By changing the width, we have to regenerate all the geometry of the elements, and it is what takes the most of the processing time. I know it is probably part of your design, but if you remove the rounded corners and the borders the tessellation should be quicker. I would be curious to test out if a 9 slice is also quicker to tessellate.

If the size of your borders are not important, you could also change the transform of the object and that will be much more efficient. This will stretch them so visually, so the tessellation step won't exist at all. One of the downside is that a border will vary in thickness: one that was 1px will reach 2px when scaled by a factor of 2, and it is going to be especially noticeable if you don't have uniform scaling (different scaling in x and y) as the border on the sides will have a different thickness compared to the one on top/bottom. That being said, because you are doing square element, it may not be noticeable.

If you go in that direction, I would recommend you to do the following: Instead of stretching every element individually, you can stretch their parent and use a group transform usage hint. This will let the GPU adjust all the mesh instead of the CPU. The simplest way to achieve this is to use the ScrollView as there is already the hint to help with the scrolling and resize the content container.

To change the scale, you will currently have to use the visualElement.transform interface in C#.

You can see one example of such resizing in shader graph and vfx graph

 

Assuming that the cell content doesn't move, the "container" of your grid should use a DynamicTransform hint, and you should set its transform to move/scale the grid. By doing so, when the grid is moved around, the transform will be applied on GPU.

 

These usage hints are made so that they do not affect the visual, but they do offer performance improvements in some conditions. The best way to see if there are relevant is to actually benchmark your usage.

https://docs.unity3d.com/ScriptReference/UIElements.VisualElement-usageHints.html
https://docs.unity3d.com/ScriptReference/UIElements.UsageHints.html

The usage hint is used when moving and resizing the "viewport" using the mouse wheel. We are not regenerating the whole content to change where/how big it is displayed. I think we may be regenerating the text, but not the borders, backgound etc...

 

We don't have this kind of optimization yet, but it's been discussed internally for use cases like GraphView derivatives (e.g. ShaderGraph) that have many identical nodes. However you could achieve this optimization on your end, through a generateVisualContent callback. For instance, the grid itself could be a single VisualElement and you could generate a custom geometry for it.

 

I was thinking you could use it for the background grid only. Your visual tree could look like this:

• GridControl
  • View <= UsageHints.DynamicTransform (the one that gets scaled/translated)
    • Cell1
    • Cell2
    • CellX
    • Grid <= generateVisualContent

With this scheme, the cells would be borderless and the grid would be generated once and drawn over the cells. The cells and the grid could use absolute positioning.

 

I meant if you want to display an actual grid (like a border around every cell). It could have been drawn by a single element. In the case of the Project Window, the scaling is fixed and there are no borders around the cells though.

 

If you want to get good performance, avoid changing the size of cells through the style, use the their transform instead, and if you plan to have them move around independently of the scrolling, set the DynamicTransform hint on them. Then the "panner" or "view" should have GroupTransform instead, since it contains tons of items with DynamicTransform. When scrolling, only change the view transform position. When changing the size, just scale the cells and move them as you wish to "wrap". This is how ShaderGraph is implemented (except that nodes don't wrap, but it's equivalent to moving nodes around).

 

We don't want them to be used "just in case", without actual reason, because then, they can degrade performance. It has to be a tradeoff. In your case, if scaling the cell content is a problem, don't hesitate to use it.

In your case, it seems that the text of the cell footer may have to be regenerated, but the content itself could be preserved and scaled. What is the content? Is it just a quad?

 

We're planning to create some samples that will illustrate this better.

In this context, I think you could get good performance if you used generateVisualContents to draw all your quads at once (maybe split them vertically into 4-5 large rows). I'm a bit worried about your text elements though. I suppose that you will be regenerating the text over and over as you scale, as the available horizontal space will increase/decrease per size, modifying the generated text mesh. Scrolling should be fast if you set the proper usage hint on your "view".

Unfortunately the geometry generation is not in a great state right now, performance-wise, so avoiding it whenever possible is the best solution. That's what we did in Graphview with UsageHints to avoid regenerating as we pan/zoom and move nodes around. But be reassured that it's on our radar and it will eventually be improved. We are explorating different strategies to address the issue, like the job system, mesh caching/reuse, compute, burst, etc.