Actually, my solution posted earlier was horrible, and shouldn’t be used. Something was gnawing at the back of my head, and was confirmed when I took another look at it with a lot more items. It is very, very inefficient choking at around 20 items for me. I still think that creating the grid beforehand is the most flexible solution though, but not for the reasons as posted above (or sort of at least).
The node you want to use for this sort of thing is the “Change Item in List”. Then it’s only a matter of calculating the index from a position in the window, get the item you want to change, do the processing, and change the item in the list. Optionally just have a different item that is the selected one. That way the rest of the list remains unchanged meaning there is no processing required for the most part. In turn this means that you can have huge selectable grids without using much processing power. This way should also be more compatible with your way of thinking about the flow if I understood you right. In the attached example I use a build list, but it is more for convenience in both testing and showing the concept. The “Build List” node can be swapped out for a list of images or objects or whatever you want to display.
So, this is the basic gist of the procedure:
I’m attaching the composition itself, and the “Grid With Index” subcomposition - because nobody wants to deal with what’s inside it on a regular basis. You will need to put this in your user modules folder along with MM.Points to make the example composition work. Not sure if it’s a user hack but I usually place my render node to the left if I need window info. There is usually only one wire going to the render node, so I’ll just hide that one and color/comment the node going to it to neaten things up.
It seems like there is some lag when starting a composition, so you’ll need to press the mouse button once after starting or resizing the window to make it display properly. I don’t know why. If @jstrecker or someone from team Vuo can take a look at it, they might have a few pointers as to why this happens though.
Using this approach a 100 x 100 grid of layers, and with mouse position as the selector still works on my old MBP. Laggy, but works, which is a feat considering it’s 10,000 layers. 200 x 200 lags to the point of breaking the composition, but if your UI depends on 40,000 separately selectable items by hovering the mouse I think you have other issues than a laggy interface. Interestingly, using mouse buttons it works with around a second of lag at 200 x 200, and technically still works at 500 x 500, but I wouldn’t call it usable. However at 250,000 layers I’m surprised it runs at all. Especially considering this is with old intel integrated gfx and Haswell series CPU. So depending on your hardware, your experience may be quite a bit different.
SelectGrid.vuo (9.92 KB)
mm.gridWithIndex.vuo (9.36 KB)