Adding an acceleration structure to CanvasLayout

[djspider117]

I love the idea for having a virtualized canvas layout but the current implementation has a somewhat big inefficiency when scaling up to extremely large numbers of objects.

I think it would be a neat idea to have the canvas items (or more specifically their spatial representation) stored in a 2d acceleration structure (QuadTree for instance). The data should still be arbitrary with no forced interface requirement, so it would have to take the bounds as an additional parameter when adding the object in.

Rebalancing operations on the tree should also be supported to avoid getting back to a O(n) situation when querying the structure.

Another type of multi-dim indexing structure would be PH-Tree .

[michael-hawker]

Thanks @djspider117, yes! We'd love CanvasLayout to be the solution for these large-scale virtualized canvas spaces.

It really started as a quick prototype to understand how well ItemsRepeater itself supported these scenarios, and there's not a lot of documentation on implementing a Layout.

One of the main challenges we still see is some scrolling issues across platforms, they all behave a bit differently. So, I'm not sure if we have a gap in a proper implementation of a Layout or exposing an issue in the platform.

I think that'd be the first piece to solve to ensure we have a stable control to work off of. Do you have any expertise in this area? I was planning to reach out to someone on the platform team now that the repo is easily accessible to demonstrate the issue.

Then it'd be great to optimize the storage of the data structure within the control itself for sure!

[djspider117]

Thanks @michael-hawker for your quick reply!
I've worked more on implementing Panel derived items rather than layouts for itemsrepeater.

I'm gonna have a go just playing around and experimenting with an RTree just to see how it would gel. The implementation should be separate enough as to not matter what the underlying control is (be it layout, panel or whathave you)

[michael-hawker]

Cool, we also have the #212 panel control as well (slightly different goals), but could be applicable there as well in the future. The CanvasView doesn't deal with the collection of data though, it just consumes it like any other panel. Though for better manipulation support, it does need to keep track of initial touch points for specific components in it, but I hit a Windows App SDK issue, so holding off on improving that at the moment from the current implementation.