I’m curious about what you mean, both in terms of “resizable” and “slices”. In particular:
Do you want edges that are:
- Smooth? (widening a row widens all rows)
- Ragged? (widening a row widens only that row)
- Sparse? (cells may be absent anywhere)
By your use of “vector”, I suspect “smooth”, as the rest likely require an indirection. But then, what kind of resizing?
-
Fixed in one direction, growable by any amount in another, origin is a corner?
In that case, “image scanout order” would likely work well (LTR, top to bottom)
-
Growable equally in two directions, origin is in a corner?
For that, perhaps progressively-larger “L” shapes, possibly alternating direction depending on how you want iteration to behave.
-
Growable equally in all directions, origin is centered?
Maybe a spiral would work best.
-
Growable in order to hold more detail, origin is on a corner?
A Hilbert curve is likely to work well.
-
Same, but centered origin?
Perhaps an H-tree
Do you plan on lots of iteration, in which case 1, 2, or 3 would likely be efficient? Exploiting locality, which makes 4 a possibility? Slicing on arbitrary boundaries, where 1 is probably more efficient than anything else?
I honestly suspect that there’s no sensible option for a “canonical resizable 2d vector”, because “resizable” has so many different options (with disjoint performance and behavioral limitations) that “canonical” seems to become impossible.
And that’s ignoring other things that, say, a map or tile grid would want - for example, a tile grid would likely want more than one of these, maybe using fixed-size scanout tiles at the finest detail for fast distance calculations from indexes (and lookups with those), while using a sparse Hilbert curve at a zoomed-out level to keep stuff likely to be accessed together nearby.
That’s not getting into more exotic stuff, like uniformly increasing the detail in one dimension (0 and 1 subdivide the field into two rows, 01 and 11 then double the vertical resolution by sitting after 0 and 1 respectively, etc).