Issue 576 in moose-technology: Border of children depends on another shape in a complex shape
Status: New Owner: ---- CC: alexandr...@gmail.com Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.4
New issue 576 by tudor.gi...@gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576
Try this, and you will see that the border around the child does not get drawn.
view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: (MORectangleShape new withoutBorder; withText). builder x:1 y:2 add: MOChildrenShape new. ]. view node: 1 forIt: [ view shape rectangle fillColor: Color red; borderColor: Color blue; borderWidth: 10. view node: 100].
If you comment withoutBorder from the top shape, the border is drawn, but only with 1 pixel. It looks like the drawing of the border of the children nodes somehow depends on the border of the other shape.
view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: (MORectangleShape new "withoutBorder;" withText). builder x:1 y:2 add: MOChildrenShape new. ]. view node: 1 forIt: [ view shape rectangle fillColor: Color red; borderColor: Color blue; borderWidth: 10. view node: 100].
Comment #1 on issue 576 by tudor.gi...@gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576
However, if the child node has children, it works as expected:
view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: (MORectangleShape new withText withoutBorder ). builder x:1 y:2 add: MOChildrenShape new. ]. view node: 10 forIt: [ view shape rectangle fillColor: Color red; borderColor: Color blue. view node: 100 forIt: [ view nodes: #(1 2 3)]]
Comment #2 on issue 576 by alexandr...@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 am not sure to understand. Why a border has to be drawn around the children? Why not to add an additional shape? Are you saying that: -=-=-=-=-= view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: MOChildrenShape new. ]. view node: 1 forIt: [ view node: 2 ]. -=-=-=-=-=
should have the very same aspect than: view node: 1 forIt: [ view node: 2 ]. ?
Why not writing: -=-=-=-=-= view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: MOChildrenShape new. builder x:1 y:1 add: (MOEllipseShape new). ]. view node: 1 forIt: [ view node: 2 ]. -=-=-=-=-=
You could then have: -=-=-=-=-= view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: MOChildrenShape new. builder x:1 y:1 add: (MOEllipseShape new). ]. view node: 1 forIt: [ view node: 2]. -=-=-=-=-=
Comment #3 on issue 576 by tudor.gi...@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 #4 on issue 576 by alexandr...@gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576
Ok, I understand. Sorry, your mail was clear at the first shoot. Apparently, this is due to displaying the text. For example, the following works as expected: -=-=-=-=-=-=-=-=-=-=-=-= view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: (MORectangleShape new fillColor: Color green). builder x:1 y:2 add: MOChildrenShape new. ]. view node: 1 forIt: [ view shape rectangle fillColor: Color red; borderColor: Color blue; borderWidth: 10; size: 90. view node: 100]. -=-=-=-=-=-=-=-=-=-=-=-=
But the following does not work: -=-=-=-=-=-=-=-=-=-=-=-= view shape form: [:builder | builder column; pref; fill; row; pref; fill; row; pref; fill. builder x:1 y:1 add: (MORectangleShape new fillColor: Color green; withText). builder x:1 y:2 add: MOChildrenShape new. ]. view node: 1 forIt: [ view shape rectangle fillColor: Color red; borderColor: Color blue; borderWidth: 10; size: 90. view node: 100]. -=-=-=-=-=-=-=-=-=-=-=-=
Working on it...
Comment #5 on issue 576 by alexandr...@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 #6 on issue 576 by tudor.gi...@gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576
Definitely, you need the shape as key!
However, forming an anonymous array as key is not nice. We should have a two level structure. First, you look for the shape and get a ElementShapeProperties. Then you look for the specific properties inside.
Comment #7 on issue 576 by alexandr...@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 #8 on issue 576 by tudor.gi...@gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576
It looks great.
How way slower? :)
Comment #9 on issue 576 by tudor.gi...@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 #10 on issue 576 by alexandr...@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 9: there is already something like this.
Comment #11 on issue 576 by tudor.gi...@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 #12 on issue 576 by alexandr...@gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576
Good news. We are actually faster.
Version 2.62 of Mondrian: metric001LinesOfCode => 19744 metric002NumberOfClasses => 174 metric003NumberOfMethods => 1986 metric004ManyEdges => 352 metric005SubnodesLookup => 2249 metric006NonVisibleEdges => 19132
Version 2.58: metric001LinesOfCode => 19355 metric002NumberOfClasses => 172 metric003NumberOfMethods => 1971 metric004ManyEdges => 2385 metric005SubnodesLookup => 1146 metric006NonVisibleEdges => 18940
Apparently, displaying many edges is faster, but looking up subnodes slightly slower.
Comment #13 on issue 576 by alexandr...@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.
Comment #14 on issue 576 by alexandr...@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 think this is fixed. We can always reopen it if the problem shows up
Updates: Status: Fixed
Comment #15 on issue 576 by tudor.gi...@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.)
look at KeySet in polymorph. It may be the answer
On Apr 11, 2011, at 8:58 PM, moose-technology@googlecode.com wrote:
Comment #6 on issue 576 by tudor.gi...@gmail.com: Border of children depends on another shape in a complex shape http://code.google.com/p/moose-technology/issues/detail?id=576
Definitely, you need the shape as key!
However, forming an anonymous array as key is not nice. We should have a two level structure. First, you look for the shape and get a ElementShapeProperties. Then you look for the specific properties inside.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
moose-technology＠googlecode.com -
Stéphane Ducasse