I think that the Mondrian facade should be rethought in the context of Roassal.
Treemaps are special cases in which a normal graph is transformed into a nested one.
Both in Mondrian and in Roassal the facade provides direct access to the inner model. But,
we could eliminate this restriction and have an intermediary model that the layout can
transform into the rendered graph. Like this, the Treemap layout would transform the flat
graph into a nested one and eliminate the edges altogether.
Cheers,
Doru
Sent from my iPhone
On May 22, 2012, at 18:43, Dennis Schenk <d.schenk(a)students.unibe.ch> wrote:
On Tue, May 22, 2012 at 5:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
On Tue, May 22, 2012 at 4:45 PM, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
The
reason is the following:
http://cl.ly/040v2X1w1V3g1o3m410A
How are the shapes actually drawn? What determines the order?
Why do you think zOrder would hamper quadtrees?
zOrder orders the elements to be drawn. Unfortunately, this order may be different from
the one specified by a user. This zOrder is one of the reason that Mondrian was not as
fast as Roassal. After some discussion with Doru, it is possible that I did not fully
understand what are the properties of the zOrder.
My understanding of z-order is that its simply a height on the z-axis. The z-axis beeing
the one which is perpendicular to the monitor surface :)
That means a shape with higher z order is in front (and thus visible) of shapes with
lower z order.
Actually, I am not completely sure whether zOrder would hamper quadtree, but it will
certainly not simplify it.
Let's try to find a easy way to solve your problem.
Will it be enough for you to provide a sorting block to reorder the nodes? I can provide
a easy way to do this.
You mean I could specify a sorting block and Roassal then draws the shapes in the
resulting order? I'm not sure - when would I set this block and when would the sorting
happen?
I don't understand the inner workings of Roassel so good yet: Where exactly in the
code are shapes drawn? At the moment, what makes a shape be in front (on the z-axis) of
another?
In the case of tree maps, it would be much better to construct nested
nodes, rather than a flat graph. This would provide the nesting by
default.
I agree, but then we would have to change the inner workings of Roassal for this specific
case? Or how would we go on about doing this?
From my side - I have nested nodes in my model, I tell Roassal (or Mondrian) about the
nesting via the edges.
Regarding zOrder, its usefulness comes when it comes to drawing edges.
Btw, zOrder does not have to be mandatory, but for it to work
efficiently, you need to be able to store this as a property in the
graph element.
Yes, for layouting the TreeMap with Mondrian I added a zOrder setter to MONode, this way
I had control over it (had the exact same problem, but it was solvable because MONode
already had the zOrder property).
Cheers,
Doru
Cheers,
Alexandre
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev