The JavaScript InfoVis Toolkit still has the edge for my needs though. The new V2 API adds treemap transition animation and the ability to nest visualizations, like having piecharts in the treemap boxes.

You can contact me at dave (at) sentrasystems.co.uk

I subscribed to the post but didn’t get an email on posts after 27th May. I was looking at JIT in nytprof, mainly because it was an already supported toolkit and that worked cross-browser. Any SVG implementation has an issue with IE and the now unsupported ASV plugin from Adobe. If it makes sense to continue with a statically generated treemap using SVG, can you send me a copy of the new nytprof so that I get a better idea of what you’d want from the final package.

I think font fitting could be dropped. It tends to distract from the boxes and there’s no great need for it. Just use a small but readable font. The names need to be written into the top label area (an area that doesn’t represent a vaue) so they’re readable and not covered by inner boxes.

I envisage tool-tip style popups on mouseover being used to convey details about what the boxes represent. Like http://blog.thejit.org/wp-content/jit-1.0a/examples/treemap.html does.

Another important technique is highlighting the chain of nested labels leading to a box. You can see it here http://demos.thejit.org/test/treemap/test4/ (though the highlight is subtle).

(Send me your email when you’ve a new version and we can discuss it that way, rather then via the blog comments :)

There’s another design I want to put up shortly that has ‘close’ boxes each of the boxes that has been zoomed, so you can zoom in/out on individual boxes.

:)
Dave

If it’s quicker you can now email me at ‘dave at sentrasystems.co.uk’

:)

How I imagine it is pretty much how http://js-treemap.sourceforge.net/tests/demo.xml.html behaves, though I’d like to be able to click on an box instead of just the label.

I hope you’re having fun!

Is this anything how you’d imagined it?

Sorry for the delay, had to learn SVG and relearn Javascript.

The examples take JSON or XML, and the JSON version doesn’t appear to require you precomputing parent sizes based on their children, something you’d need to do in any Treemap::Input module you wrote (Treemap needs a Treemap::Input::[Dir|XML|...] object to manipulate).

Thoughts?

:) Dave

I see your point about the blocks being pre-sized, making drill-down on the client a tricky problem. Umm. Though I guess it’s only really a problem if you want the drilled-into subsection of the tree to be ‘fully fitted’ into the viewing frame. We don’t really need that. So here’s an idea: perform drill-down by effectively SVGZoomAndPan’ing or SVGFitToViewBox’ing such that the section of the treemap that was clicked on now fills either the width or height of the viewport, whichever comes first. (I say ‘effectively’ because I’ve only spent 5 minutes skimming the SVG spec to find some straws for me to clutch! There’s quite possibly a better way.)

Re getting the data into the treemap, I’d make Treemap::Output::SVG an optional dependency for Devel::NYTProf. If it’s installed then the nytprofhtml script would automatically use it to generate a treemap svg file and write a modified index page that would refer to the svg.

How do you envisage the drilldown working? Do you show one level of calls/statements per page, with each call drilling down to the next level of calls below. I’ve generated a simple Treemap::Output::SVG module that does the same as the equivalent Treemap::Output::Imager module. It doesn’t do drill down yet, and the nature of the Treemap module means that all the blocks are sized in the Treemap module itself, which (presumably) wouldn’t work well if you want to drill down through a call to a full sized page.

How did you envisage getting input into the Treemap? A Treemap::Input::Devel::NYTProf module, via the Treemap::Input::XML module or some other way?

If you drop me an email I can send you the Treemap::Output::SVG module source, it’s not on CPAN as it’s only a proof of concept at the moment.

:)

Dave

I’m immediately interested in the size of things in memory for now.

Josh