That is my point: it takes too much finger work to zoom out far enough. A few (3-4) distinct stages would speed up things as smoothness / granularity as a feature is not helpful in this case. You probably didn't say to yourself: Damn, I'd like to see the node tree 3% smaller...

Good job man!

I think the problem is not calculation speed but knowing what needs calculating. Unfortunately you, the developer, can not know what the end user considers important or what calculation lag is still acceptable UX wise.
A solution to the first unknown is to make it easy for the users to express what they deem important, UI polish. For the second part I could imagine a progressive update method: you always spend a fixed, interaction friendly amount of time in each time unit to update as many previews as possible. Outdated-ness is indicated instantly but refresh is spread out, done over time on the whole tree.

(v0.23: Cool! :)

Hmm, an extra tab doesn't really help unless you use a single viewport layout. (There is no simple way to switch from full screen SF to 2x2 split scene views.)

Ah, good point, I'll do that.

Yes, I explicitly set it to (999999f,99999f) but still couldn't pull wider than the width of my main display, 1920 pixels. In certain cases when I move an editor window around and it overlaps the second screen too much it even shrinks down to that size (1280x1024).

Oh indeed, just checked, EditorWindow.maxSize is quietly clamped to main screen dimensions. :(

Not anymore. However a friend on pro tried your example and it works fine.

You are probably right, I found a shader using depth to highlight intersections, doesn't look as expected.

Yes, I am looking through the ingame camera. The only difference between the editor and ingame cameras seems to be that in editor view the background is covered up by the test box.