Peformance Improvement in Google TreeMap API

It was so much fun, to play around with Google treeMap API over a month. Currently I'm working on an application which heavily uses this API , to handle  huge amount of  data retrieval from the back end. It was trivial, to figure out a way to improve the performance of the application, which was heavily dependent on this on line Google treeMap. The answer was to draw the hierarchical information layer by layer of  the tree Map, as in each left click , there will be a server call to retrieve the  next level data set.
(Anyhow, if you want to get started with google API, they have provided a cool on line example which you can try out  first and understand the depth of the API very fast. It will brief you how dose it load and prepare a whole set of data array to populate  in each layer at one shot.Also this example helps out to understand how to organize the data array to draw it layer by layer)

So,  in my business problem, the application uses Google API to show some code dependency change information.So the treeMap has  used to show case which piece of code unit  (package,classes,methods) of a code base has changed and it indicates the heaviness of the change with  a defined color code. Here we have made an assumption that we analyze dependencies for  a code base which is written either java/.NET. In the TreeMap,  first of all,  I would see the module level changes of a project. As I drill down, the treeMap will show, the next level changes. For example if you see the module level changes now, modules includes packages, so in the current layer it will indicate that there are changes in packages level with a reddish color range .Likewise it will show the changes for ,classes  and method as well.

Drawing two layers to show changes in the treeMap , doesn't  harm the left click event and  it  helps to drastically improve the performances of the application.But, the problem comes when you roll up, on the right event which always need a parent level with data  to be rolled up to the next level.So once you right click on the method level changes(roll up( )) ,and tried to see class level code changes it will work out.But when you right click (plain) again on classes level and roll up to the package level,  the right click event will not fire. Then you can't view the package level changes in backward.

It's quite challenging to customize an API  and stop running certain features which are already featured to have with it and designed. Trying with a dummy parent also didn't work out to trigger a right click event at upper level , when it doesn't have a parent. Basically,  the solution was to draw the tree map single layer by layer. So, that you can assume,  there is no such a parent layer at all.
What would remind you the following picture ? Some color play on a puzzle game? or else Wesak?;) You name it what ever it pops in your mind. Anyways,  Isn't it beautiful color combination?

Technically, trust me when I say that each and every small piece of squares indicates a code unit (package,class or a method ) according to my business problem. The lager squares, separated with a white color border are indicated the present layer  component,a package.( Since  I  have already drilled it down to one layer bellow from module level). So yellow to Red color code range indicates, that there are code unit changes in other bottom layers. Data capturing for a change of code unit is done by using another propriety, third party tool . The google tree map is simply used  here to present the data in a proper hierarchical structure.

Even though,  you go for the option of drawing tree map layer by layer ,  in  parallel, there will be a server call  for each layer to draw, which dose the data population. If your server calls are heavy,  that will automatically drop the performance of your web application drastically. So it should be a careful thinking ,analyzing and moderating google treemap to enhance the performance of it in  this way.