First Impressions

I like it; the treemap tiles are much more square than before.

But there is a caveat: The shading is too pronounced in some cases, up to a point where the largest tiles all drown out in a dark mush; see screenshots below.

Comparison Old and New

/usr on my OpenSUSE Leap 15.5

Old

New

My Home Directory

Old

Notice how you can see the treemap tile boundaries in the top left corner; which is important to compare them against each other.

New

Notice how the boundaries between the tiles became invisible in the top left corner with all that dark shading.

With a click into that area, the boundary of that one tile becomes visible.

If I understood you correctly, the new algorithm adds more ridges; one for each subdivision. Correct?

If that is indeed the case, the "height" of the ridge (i.e. the light falloff) could probably be tweaked to make each ridge less pronounced so there is less contrast for each one. Could you try that?

Maybe also changing the direction where the light comes from might help; top left instead of (how it looks to me) bottom right. That might put more light on the important tiles, the largest ones which are on the top left.

There aren't any more ridges than before, but the row ridges are much smaller and it produces more contrast and hence darker darks. I agree the general appearance is darker, possibly too dark. That can be tweaked with one of three settings:

1. CushionHeight, currently hard-coded to 1.0, but lower values will brighten the dark areas. A value of 0.5 or 0.6 might work as a default setting, it should probably be configurable because this is perhaps the most important and useful setting. You can also try above 1.0 but probably not useful in practice.
2. HeightScaleFactor, already configurable. It is the amount by which the cushion height is decreased at each tree level. Currently defaults to 0.8 which is good. Lower values will tend to wash out the cushions although that does brighten the darker areas. 0.9 or 1.0 will produce more definition on the leaf tiles but may be too dark without adjusting other settings.
3. AmbientLight, also configurable. It sets a lower limit on the darkest shadows and brightens everything else proportionally. It obviously brightens the darker areas but again tends to reduce the contrast.

The original papers fixes ambient light at 40, and considers the other two to be configurable to taste, although it suggest a cushion height of 0.5 and height factor of between 0.5 and 1.0. The examples they show are of white cushions (I think, the paper is in black and white), so not quite as dark as using colours.

About the "extra" row cushion. It doesn't really exist! Squarified tile cushions are deformed in both the x and y directions. In a single row, the coefficients along the short axis are identical for every tile in the row, so they can all be created at once and then that cushion surface (its coefficients and height) inherited down to the individual tiles. The row cushion is then forgotten and it isn't rendered separately. Or you can think of it as a row cushion with bumps along it if you like, but the row cushion isn't there in the final treemap.

The height scale factor is only ever applied at the creation of new tiles inside a parent directory. This should probably be done in the constructor and the ability to change the height manually could be removed, but that would make it tricky to factor down the height for the dummy row cushion, because it needs its height reduced by the scale factor to match the child tiles that haven't yet been created.

Anyway, I think the calculation is correct in this code, although like a lot of things it could be tidied up and speeded up.

I just merged this into a new feature branch better-treemap for parameter tweaking before merging that branch into master.

Thank you for your contributions!

I finally found time to tune those treemap shading parameters a bit. This is the preliminary outcome:

That old factor of a constant 4.0 in the addSquareRidge() and addLinearRidge() functions has now become a somewhat dynamic one; it's now degressive the more ridges are added, so deeply nested treemaps don't look so dark anymore, yet shallow trees don't just become washed out with very light colors.

I think we can live with that result. I'll still play around a bit with it, and then I will probably merge the branch to master.

That's pretty much what the height scale factor does, although it doesn't stop at a depth of five tiles. The 4.0 is a holdover from the illumination calculations. Really you're working with a height of 4.0 times the nominal height. The equivalent figures for the official algorithm with a height of 0.6 (4*height=2.4) and a scale factor of 0.8 are:
2.4
1.9
1.5
1.2
1.0
Note that the scale factor calculation in my code is applied once per tile, not one per ridge. If you still have the scale factor code in (and configured to be less than 1.0) then the height will be changing in addition to your factor.

I experimented quickly with capping the height scale factor at a height of 1.0 (starting from 4*0.6) . Less effect than I expected. Very slightly darker than the equivalent uncapped configuration. In theory, it should give very slightly darker shadows on the leaf-level tiles, but not on the larger top-level tiles.

See also the summary in #236.