Squarify algorithm unresponsive to changed aspect ratio. about d3-hierarchy

[jheer]

🎉

[mbostock]

This is the expected behavior, but I agree it should at least be better documented. If you don’t want a stable update, you can use root.copy to create a fresh hierarchy and pass that to the treemap.

[mbostock]

Some possible API improvements:

1. Make the cached layout (_squarify) specific to the aspect ratio, such that if the aspect ratio changes, a new layout is computed from scratch. This seems reasonable, although a little magical.
2. Make opting out of the stable update more obvious, say d3.treemapSquarify.stable(false). I don’t know if this is significantly better than just improving the API documentation, however.
3. Make opting in to the stable update explicit, say by exposing d3.treemapResquarify as a tiling algorithm (that requires the input to have been previously computed using d3.treemapResquarify… or possibly d3.treemapSquarify?).
4. Generalize stable updates to the treemap (#36), i.e., like the previous approach, you might use d3.treemapSquarify to compute the initial layout, and then d3.treemapStable to update that layout with new values. The stable update wouldn’t rely on hidden fields (_squarify); it would automatically determine topology of the previous layout and preserve it on update.

[jheer]

Generalized stable updates sounds quite attractive! In that case, might the top-level treemap method accept a stable parameter to opt-in or opt-out of stable updates? (Not unlike sticky in D3 v3, but all the more reasonable if shared across tiling methods.) From the perspective of higher-level tools built on top of D3, it would be expedient to be able to parameterize the treemap once and have it behave appropriately, rather than swapping tiling methods around for the sake of stable layout.

One additional benefit might be some memory savings for very large trees. When stable === false the layout need not generate and cache partition decisions. However, one must consider the case when toggling the stable value. If toggled from false to true, should the layout cache the current layout or only future layout runs? I find the latter is reasonable (and simpler to implement).

[mbostock]

I’ve implemented the third proposal in #46. Care to take a look?

For generalized stable update, I was imagining that you’d use d3.treemapStable to update an existing treemap’s layout, rather than needing to set tile.stable(true) on each tiling function. The problem with the latter approach is that it requires each tiling function to expose a stable parameter, and given that it’s easy for people to writing tiling functions outside the library, it’d be better to centralize the stable update logic.

I suppose another way to do it, though, would be to set treemap.stable(true), which could override the treemap’s tiling function (treemap.tile) and instead use treemapStable, which could then just be a private internal function. (Or it could still be public… it doesn’t matter.) Though then you’d need some additional logic to detect whether a layout was previously computed, but that could potentially be as simple as checking whether node.x0 is defined.

Anyhow, a generalized stable update is still theoretical at this point. I took a brief crack at it previously and wasn’t successful, though I still think it should be possible.

The proposed implementation in #46 avoids saving the partition decisions if you use d3.treemapSquarify rather than d3.treemapResquarify. (Though the objects are created internally and then discarded to simplify the implementation. I could optimize that, I suppose, but it’d make the logic a bit more complicated.)

[jheer]

Thanks! #46 is definitely an improvement, and a good working solution in the absence of generalized stable updates.

[mbostock]

Thanks for the feedback. I’ll push a new patch release shortly.

[mbostock]

Released in 0.2.4.