Comment #3 on issue 576 by tudor.gi...(a)gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576 I was talking about the shape of the node (100 in my example) from inside the top node (1). Node 100 should be shown with a rectangle with a blue border, but it is not. The problem is somehow related to the "withoutBorder" from the definition of the shape of node 1.

Comment #5 on issue 576 by alexandr...(a)gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576 I found the problem. It is due to the cache. Currently, each node contains a dictionary referenced by a variable called "attributes". This dictionary maps metrics to values. For example, if I have a script like "view node: 'hello'", then the MONode that represents 'hello' will have the attributes dictionary full of associations like: {cacheWidthFor: -> 5, cacheHeightFor: -> 5, cacheborderWidthFor:-> 1}. Everything is okay so far. The basic assumption behind the cache, is that a MONode can have only one graphical representation. This assumption is wrong because of the formbuilder. When I first designed the cache, the forms builder was quite mysterious to me. I better understand the implications now. For the upper shape (MORectangleShape new fillColor: Color green; withText), the border width is 1. For "view shape rectangle fillColor: Color red; borderColor: Color blue; borderWidth: 10; size: 90", the border width is 10. So, two different values for the same MONode. I will update the cache to have something like: {(shape1, cacheWidthFor:) -> 5, (shape1, cacheHeightFor:) -> 5, (shape1, cacheborderWidthFor:)-> 1, (shape2, cacheborderWidthFor:)-> 10} This will have an impact on performance. How does that sound?

Comment #7 on issue 576 by alexandr...(a)gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576 I implemented the cache system I described earlier. This fixes the bug. However, Mondrian is way slower. I have some idea on how to make it faster. Doru, can you try this new version and try the form builder please? Version 2.62

Comment #9 on issue 576 by tudor.gi...(a)gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576 Here is an idea. In VW, we had a cache only for bounds. That can be a one level dictionary with a shape as a key. Then you can use the two level cache for the other properties that do not necessarily affect the bounds.

Comment #11 on issue 576 by tudor.gi...(a)gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576 I expressed it badly. What I meant to say was that maybe the performance would not be so bad if the cache with the bounds would still remain a one-level-of-indirection-cache, and only use the two-level-indirection (dictionary in dictionary) for the individual properties. Actually, in VW we only had the cache for the bounds, and the properties were always computed on the fly, and it was still fine. So, I come back to the original question, what is the penalty introduced by your fix?

Comment #13 on issue 576 by alexandr...(a)gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576 Comment 11: Actually I had an impression of slowness. I try to measure it, and I could not find it. So I do not believe we are slower.

Updates: Status: Fixed Comment #15 on issue 576 by tudor.gi...(a)gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576 (No comment was entered for this change.)