Pages which create a Canvas instance (new Canvas()) can be seen to have an increase in memory (at least in FF/Mac) which is proportional to the size of the created Canvas.
I first observed this when working with the Spacetree. The behavior can be seen on the example page but is small (~2MB) because of the size of the Canvas. Altering the example to use a 1000px X 1000px canvas will show a more dramatic (~25-50 MB) increase.
Seeking to isolate the cause and symptoms, I created these 3 pages:
http://jfsiii.org/testpages/tagcanvas.html - 4000px X 4000px Canvas using only the canvas tag
http://jfsiii.org/testpages/classcanvas.html - 4000px X 4000px Canvas using new Canvas()
* http://jfsiii.org/testpages/classcanvasgc.html - 4000px X 4000px Canvas using new Canvas() and deleting the variable when the page unloads
I assume that you are talking about the spacetree. The fundamental idea of the spacetree is that it uses the available space to its best. On a left-oriented spacetree canvas-height can pose an ugly constraint forcing the user to "scroll" the content into the available space by clicking on one of the outer-most nodes. In my opinion scrolling the canvas would blur the characteristics of a spacetree. Maybe it would be better to automatically divide the subtree into n subtrees that each fit into the available space. Each subtree should be named automatically, for instance, "1 to 40 of 79" and "41 to 79 of 79". This way you would introduce new "artificial" levels but stay on the canvas. I think users are quite used to this kind of "page 2 of 3" idioms. And it's easier to remember on which subtree "page" you were than the position of your vertical scrollbar.
scrolling support would be a greatgreat thing actually. implementing this "pagination" solutino does not make sense in a lot of cases.