Hi
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal.
Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest.
In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure.
So I would like to know.
Stef
+1 :-)
On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse stephane.ducasse@inria.frwrote:
Hi
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal.
Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest.
In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure.
So I would like to know.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
No, we haven't decided exactly what will be the plan for the GSoC for Mathieu because in the last meeting we talked about what is he currently doing, integrate part of that and decided what to do next with some of his current work. And yes, we need to make it asap.
Yes, we plan to use Athens transformation in the future, but the thing is that I don't think all our performance problems come from the platform. Because of this I don't think that all our problems will be fixed with Athens. For example the events generation, we might be generating too many.
Vanessa.
On 06/05/2013 04:06 AM, Usman Bhatti wrote:
+1 :-)
On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse <stephane.ducasse@inria.fr mailto:stephane.ducasse@inria.fr> wrote:
Hi I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal. Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest. In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure. So I would like to know. Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 5, 2013, at 9:45 PM, Vanessa Peña Araya van.c.pena@gmail.com wrote:
Hi,
No, we haven't decided exactly what will be the plan for the GSoC for Mathieu because in the last meeting we talked about what is he currently doing, integrate part of that and decided what to do next with some of his current work. And yes, we need to make it asap.
ok Because mathieu will have a short GSOC.
Yes, we plan to use Athens transformation in the future, but the thing is that I don't think all our performance problems come from the platform. Because of this I don't think that all our problems will be fixed with Athens. For example the events generation, we might be generating too many.
Yes probably but the obvious first :) Because once you know you remove part. I do not know if you loaded the visualization igor did with athens and they were a lot of bezier and they were smooth.
For your information we will push athens in Pharo really soon now. Normally it was planned for end of the last week but we got problem with our servers.
Stef
Vanessa.
On 06/05/2013 04:06 AM, Usman Bhatti wrote:
+1 :-)
On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse stephane.ducasse@inria.fr wrote: Hi
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal.
Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest.
In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure.
So I would like to know.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I do not know if you loaded the visualization igor did with athens and they were a lot of bezier and they were smooth.
The difficult thing is to handle the interaction (e.g., turning the bezier curve red as soon as the mouse is above it). I believe this is where most of the resources are wasted so far. But yes, integrating Athens more in Roassal by using matrixes is really important.
For your information we will push athens in Pharo really soon now. Normally it was planned for end of the last week but we got problem with our servers.
That is a very good news!!!!
Alexandre
On 06/05/2013 04:06 AM, Usman Bhatti wrote:
+1 :-)
On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse stephane.ducasse@inria.fr wrote: Hi
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal.
Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest.
In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure.
So I would like to know.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list
Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Wed, Jun 5, 2013 at 9:45 PM, Vanessa Peña Araya van.c.pena@gmail.comwrote:
Hi,
No, we haven't decided exactly what will be the plan for the GSoC for Mathieu because in the last meeting we talked about what is he currently doing, integrate part of that and decided what to do next with some of his current work. And yes, we need to make it asap.
Yes, we plan to use Athens transformation in the future, but the thing is that I don't think all our performance problems come from the platform. Because of this I don't think that all our problems will be fixed with Athens. For example the events generation, we might be generating too many.
I am not sure event generation is the only thing we would like to concentrate during the GSOC because there can be other optimizations. The thing is that the current work is as interesting as improving the performance of Roassal. But we'll have to set priorities at the end we might not have enough time to profile and improve all the points impacting the performance in Roassal.
usman
Vanessa.
On 06/05/2013 04:06 AM, Usman Bhatti wrote:
+1 :-)
On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal.
Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest.
In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure.
So I would like to know.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi
I think there are two different points :
1 - The layout algorithms should be improved to reduce their complexity. ( maybe I should implement a "true" force based, I mean that I translated the D3 algorithm, but thinking of it now, maybe it would have been better to take a real algorithm from a paper and to implement it from scratch ).
2 - Even if I'm not playing with the mouse, when the visualization is the active window then the computer turns. My CPU runs mad when the visualization is active in Pharo, and that must not be. There is no reason for your computer to turn if the visualization is already drawn and you don't do anything on it.
That is two different things. Layouts may be long to compute, when you display a thousand edges and nodes with a grid layout, it should be fluent.
Regards
Mathieu
I think the goal of this GSoC must be to get Roassal fluent once the layout is shown.
And if I have time then, or if someone want to do it, we should implement a real force layout, and improve other ones.
Regards
Math
1 - The layout algorithms should be improved to reduce their complexity. ( maybe I should implement a "true" force based, I mean that I translated the D3 algorithm, but thinking of it now, maybe it would have been better to take a real algorithm from a paper and to implement it from scratch ).
It depends. You need to have a sophisticated algorithm (probably based on quadtree as done in D3) to have it fast.
2 - Even if I'm not playing with the mouse, when the visualization is the active window then the computer turns. My CPU runs mad when the visualization is active in Pharo, and that must not be. There is no reason for your computer to turn if the visualization is already drawn and you don't do anything on it.
Yes, you spotted a nice problem. We are aware of it but haven't found a nice solution to it. A smarter way to generate event is indeed needed.
We left some todos from our last meeting, were you able to make progress on them? If yes, then you should focus on using Athens Matrixes. This is on our todo list for a long time. Using Athens may speed up Roassal, but I doubt it will make Roassal scale up to many more nodes. Who knows....
Cheers, Alexandre
Le 06.06.2013 15:41, Alexandre Bergel a écrit :
1 - The layout
algorithms should be improved to reduce their complexity. ( maybe I should implement a "true" force based, I mean that I translated the D3 algorithm, but thinking of it now, maybe it would have been better to take a real algorithm from a paper and to implement it from scratch ).
It depends. You need to have a sophisticated algorithm (probably
based on quadtree as done in D3) to have it fast.
2 - Even if I'm
not playing with the mouse, when the visualization is the active window then the computer turns. My CPU runs mad when the visualization is active in Pharo, and that must not be. There is no reason for your computer to turn if the visualization is already drawn and you don't do anything on it.
Yes, you spotted a nice problem. We are aware of it
but haven't found a nice solution to it. A smarter way to generate event is indeed needed.
We left some todos from our last meeting, were
you able to make progress on them? If yes, then you should focus on using Athens Matrixes. This is on our todo list for a long time.
Using Athens may speed up Roassal, but I doubt it will make Roassal scale up to many more nodes. Who knows....
Cheers,
Alexandre
About my todos list.
Well, now compact trees take care of nodes size. Radial tree also but I still have a little something to add to it.
I do not have change anything in Bezier curves and the way the interact with canvas, but I can do it when working on canvas later.
But by now, I have to write papers for school, so I don't have much time to spend on the code. (abstract, report ...)
I'll be back soon on Roassal.
Regards
Math
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com
n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has
really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then
it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks Fabrizio. We have found where the problem comes from. Give us a couple of hours :-)
Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Stupid problem it was. The ROView object keeps a list of elements that are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it. However this is completely unnecessary.
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Stupid problem it was. The ROView object keeps a list of elements that are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it. However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi, I just tried it out at now it is definetly faster. It is fast enough to be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
Thanks really really a lot Alex.
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Stupid problem it was. The ROView object keeps a list of elements that
are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it.
However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse stephane.ducasse@inria.fr
wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering
elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com
wrote:
Hi, to have fast algorithms to layout the elements is very good, but a
visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy
to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more
scalable in term of interaction and not in term of initial rendering.
Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does
n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
> Hi > > I've made some tests on the force based layout, and it seems it has
really a complexity in nlog(n) (and we cannot do really better).
> > Thus when you take 3 seconds to compute a layout with 100 nodes,
then it's normal to take 40 seconds with 1000 nodes.
> > > Regards > > Mathieu > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Mon, Jun 17, 2013 at 8:28 AM, Fabrizio Perin fabrizio.perin@gmail.comwrote:
Hi, I just tried it out at now it is definetly faster. It is fast enough to be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
+1 :)
Thanks really really a lot Alex.
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Stupid problem it was. The ROView object keeps a list of elements that
are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it.
However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering
elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com
wrote:
Hi, to have fast algorithms to layout the elements is very good, but a
visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy
to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more
scalable in term of interaction and not in term of initial rendering.
Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what
does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
> Hi Mathieu, > > We will have a look at this asap > > Alexandre > > > On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote: > >> Hi >> >> I've made some tests on the force based layout, and it seems it
has really a complexity in nlog(n) (and we cannot do really better).
>> >> Thus when you take 3 seconds to compute a layout with 100 nodes,
then it's normal to take 40 seconds with 1000 nodes.
>> >> >> Regards >> >> Mathieu >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I just tried it out at now it is definetly faster. It is fast enough to be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
Having scrollbars is on our todos for a long time. Juraj will implement one on some point. In the meantime, have you tried the minimap? This is pretty cool.
Doit the following and press the key m: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Source code: ROMondrianExample>>miniMapOn:" "Preambule. It includes the initialization. " | view rawView | rawView := ROView new. view := ROMondrianViewBuilder view: rawView. "-------------" "-------------"
view raw @ (ROMiniMap new targetView: view stack). "press m to open the view minimap " view shape rectangle width: [ :cls | cls numberOfVariables * 5 ]; height: #numberOfMethods; linearFillColor: #numberOfLinesOfCode within: Collection withAllSubclasses. view interaction popupText: [ :cls | cls name, (String with: Character cr), cls methods size printString, ' methods', (String with: Character cr), cls instVarNames size printString, ' variables', (String with: Character cr), cls numberOfLinesOfCode printString, ' LOC' ]. view interaction action: #browse.
view nodes: Collection withAllSubclasses. view edgesFrom: #superclass. view treeLayout.
"-------------" "-------------" "Below is the initiation of the menu and opening the visualization" ROEaselMorphic new populateMenuOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexandre
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Stupid problem it was. The ROView object keeps a list of elements that are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it. However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
> Hi > > I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). > > Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. > > > Regards > > Mathieu > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
I just tried it out at now it is definetly faster. It is fast enough to be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
Having scrollbars is on our todos for a long time. Juraj will implement one on some point. In the meantime, have you tried the minimap? This is pretty cool.
Yes it is. MiniMap is not working in Glamour-Roassal, so if someone can have a look, it'll be great.
Doit the following and press the key m:
"Source code: ROMondrianExample>>miniMapOn:" "Preambule. It includes the initialization. " | view rawView | rawView := ROView new. view := ROMondrianViewBuilder view: rawView. "-------------" "-------------"
view raw @ (ROMiniMap new targetView: view stack).
"press m to open the view minimap "
view shape rectangle width: [ :cls | cls numberOfVariables * 5 ]; height: #numberOfMethods; linearFillColor: #numberOfLinesOfCode within: Collection withAllSubclasses.
view interaction popupText: [ :cls | cls name, (String with: Character cr), cls methods size printString, ' methods', (String with: Character cr), cls instVarNames size printString, ' variables', (String with: Character cr), cls numberOfLinesOfCode printString, ' LOC' ]. view interaction action: #browse.
view nodes: Collection withAllSubclasses. view edgesFrom: #superclass. view treeLayout.
"-------------" "-------------" "Below is the initiation of the menu and opening the visualization" ROEaselMorphic new populateMenuOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexandre
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Stupid problem it was. The ROView object keeps a list of elements that
are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it.
However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse stephane.ducasse@inria.fr
wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering
elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com
wrote:
Hi, to have fast algorithms to layout the elements is very good, but a
visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy
to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more
scalable in term of interaction and not in term of initial rendering.
Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does
n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
> Hi > > I've made some tests on the force based layout, and it seems it has
really a complexity in nlog(n) (and we cannot do really better).
> > Thus when you take 3 seconds to compute a layout with 100 nodes,
then it's normal to take 40 seconds with 1000 nodes.
> > > Regards > > Mathieu > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Why is this not working? Can you give a complete script that we can start from?
Cheers, Alexandre
On Jun 17, 2013, at 10:47 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
I just tried it out at now it is definetly faster. It is fast enough to be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
Having scrollbars is on our todos for a long time. Juraj will implement one on some point. In the meantime, have you tried the minimap? This is pretty cool.
Yes it is. MiniMap is not working in Glamour-Roassal, so if someone can have a look, it'll be great.
Doit the following and press the key m:
"Source code: ROMondrianExample>>miniMapOn:" "Preambule. It includes the initialization. " | view rawView | rawView := ROView new. view := ROMondrianViewBuilder view: rawView. "-------------" "-------------"
view raw @ (ROMiniMap new targetView: view stack).
"press m to open the view minimap "
view shape rectangle width: [ :cls | cls numberOfVariables * 5 ]; height: #numberOfMethods; linearFillColor: #numberOfLinesOfCode within: Collection withAllSubclasses. view interaction popupText: [ :cls | cls name, (String with: Character cr), cls methods size printString, ' methods', (String with: Character cr), cls instVarNames size printString, ' variables', (String with: Character cr), cls numberOfLinesOfCode printString, ' LOC' ]. view interaction action: #browse.
view nodes: Collection withAllSubclasses. view edgesFrom: #superclass. view treeLayout.
"-------------" "-------------" "Below is the initiation of the menu and opening the visualization" ROEaselMorphic new populateMenuOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<Screen Shot 2013-06-17 at 9.28.21 AM.png>
Alexandre
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Stupid problem it was. The ROView object keeps a list of elements that are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it. However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
> Hi Mathieu, > > We will have a look at this asap > > Alexandre > > > On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote: > >> Hi >> >> I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). >> >> Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. >> >> >> Regards >> >> Mathieu >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Alex, Probably its the way keyboard shortcuts are handled in Glamour. ========================================================== This is not working:
| browser viewHack | browser := GLMTabulator new. browser column: #list; column: #drawing.
browser transmit to: #list; andShow: [ :a | a list ]. browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | moview raw @ (ROMiniMap new targetView: moview stack). collection do: [ :x | moview view add: (ROElement spriteOn: x) + ROLabel + ROBox white ]. ROVerticalLineLayout on: moview view elements.
viewHack := moview view. ] ].
browser openOn: #(1 2 3 4 5 6).
====================================================================== But this does: | browser viewHack | browser := GLMTabulator new. browser column: #drawing.
browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | moview raw @ (ROMiniMap new targetView: moview stack). collection do: [ :x | moview view add: (ROElement spriteOn: x) + ROLabel + ROBox white ]. ROVerticalLineLayout on: moview view elements.
viewHack := moview view. ] ].
browser openOn: #(1 2 3 4 5 6).
So may be we need to invoke the mini map without keyboard shortcuts.
usman
On Mon, Jun 17, 2013 at 5:23 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Why is this not working? Can you give a complete script that we can start from?
Cheers, Alexandre
On Jun 17, 2013, at 10:47 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
I just tried it out at now it is definetly faster. It is fast enough to
be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
Having scrollbars is on our todos for a long time. Juraj will implement
one on some point.
In the meantime, have you tried the minimap? This is pretty cool.
Yes it is. MiniMap is not working in Glamour-Roassal, so if someone can
have a look, it'll be great.
Doit the following and press the key m:
"Source code: ROMondrianExample>>miniMapOn:" "Preambule. It includes the initialization. " | view rawView | rawView := ROView new. view := ROMondrianViewBuilder view: rawView. "-------------" "-------------"
view raw @ (ROMiniMap new targetView: view stack). "press m to open the view minimap " view shape rectangle width: [ :cls | cls numberOfVariables * 5 ]; height: #numberOfMethods; linearFillColor: #numberOfLinesOfCode within: CollectionwithAllSubclasses.
view interaction popupText: [ :cls | cls name, (String with: Character cr), cls methods size printString, ' methods', (String with:Character cr),
cls instVarNames size printString, ' variables', (Stringwith: Character cr),
cls numberOfLinesOfCode printString, ' LOC' ]. view interaction action: #browse. view nodes: Collection withAllSubclasses. view edgesFrom: #superclass. view treeLayout."-------------" "-------------" "Below is the initiation of the menu and opening the visualization" ROEaselMorphic new populateMenuOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<Screen Shot 2013-06-17 at 9.28.21 AM.png>
Alexandre
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Stupid problem it was. The ROView object keeps a list of elements
that are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it.
However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still
rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin <
fabrizio.perin@gmail.com> wrote:
> Hi, > to have fast algorithms to layout the elements is very good, but a
visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
> > The same visulization opened with a MOViewRenderer was nice and
easy to interact with and to browse.
> > So, my point is that the priority is absolutly to make roassal
more scalable in term of interaction and not in term of initial rendering.
> Cheers, > Fabrizio > > > 2013/6/8 Tudor Girba tudor@tudorgirba.com > n log(n) sounds quite good for this kind of algorithm. But, what
does n mean? Is it the amount of nodes, or the amount of edges as well?
> > Doru > > > On Jun 7, 2013, at 6:18 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
> >> Hi Mathieu, >> >> We will have a look at this asap >> >> Alexandre >> >> >> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote: >> >>> Hi >>> >>> I've made some tests on the force based layout, and it seems it
has really a complexity in nlog(n) (and we cannot do really better).
>>> >>> Thus when you take 3 seconds to compute a layout with 100 nodes,
then it's normal to take 40 seconds with 1000 nodes.
>>> >>> >>> Regards >>> >>> Mathieu >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Here is a solution: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | browser | browser := GLMTabulator new. browser column: #list; column: #drawing.
browser transmit to: #list; andShow: [ :a | a list ]. browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | | m | m := ROMiniMap new. moview raw @ m. collection do: [ :x | moview view add: (ROElement spriteOn: x) + ROLabel + ROBox white ]. ROVerticalLineLayout on: moview view elements.
moview addMenu: 'map' callBack: [ :viewStack | m openMiniMapFor: viewStack ].
] ].
browser openOn: #(1 2 3 4 5 6). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Probably not ideal, but it seems to do what you may need.
Cheers, Alexandre
On Jun 17, 2013, at 12:34 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
Alex, Probably its the way keyboard shortcuts are handled in Glamour. ========================================================== This is not working:
| browser viewHack | browser := GLMTabulator new. browser column: #list; column: #drawing.
browser transmit to: #list; andShow: [ :a | a list ]. browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | moview raw @ (ROMiniMap new targetView: moview stack). collection do: [ :x | moview view add: (ROElement spriteOn: x) + ROLabel + ROBox white ]. ROVerticalLineLayout on: moview view elements. viewHack := moview view. ] ].
browser openOn: #(1 2 3 4 5 6).
====================================================================== But this does: | browser viewHack | browser := GLMTabulator new. browser column: #drawing.
browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | moview raw @ (ROMiniMap new targetView: moview stack). collection do: [ :x | moview view add: (ROElement spriteOn: x) + ROLabel + ROBox white ]. ROVerticalLineLayout on: moview view elements. viewHack := moview view. ] ].
browser openOn: #(1 2 3 4 5 6).
So may be we need to invoke the mini map without keyboard shortcuts.
usman
On Mon, Jun 17, 2013 at 5:23 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Why is this not working? Can you give a complete script that we can start from?
Cheers, Alexandre
On Jun 17, 2013, at 10:47 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
I just tried it out at now it is definetly faster. It is fast enough to be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
Having scrollbars is on our todos for a long time. Juraj will implement one on some point. In the meantime, have you tried the minimap? This is pretty cool.
Yes it is. MiniMap is not working in Glamour-Roassal, so if someone can have a look, it'll be great.
Doit the following and press the key m:
"Source code: ROMondrianExample>>miniMapOn:" "Preambule. It includes the initialization. " | view rawView | rawView := ROView new. view := ROMondrianViewBuilder view: rawView. "-------------" "-------------"
view raw @ (ROMiniMap new targetView: view stack). "press m to open the view minimap " view shape rectangle width: [ :cls | cls numberOfVariables * 5 ]; height: #numberOfMethods; linearFillColor: #numberOfLinesOfCode within: Collection withAllSubclasses. view interaction popupText: [ :cls | cls name, (String with: Character cr), cls methods size printString, ' methods', (String with: Character cr), cls instVarNames size printString, ' variables', (String with: Character cr), cls numberOfLinesOfCode printString, ' LOC' ]. view interaction action: #browse. view nodes: Collection withAllSubclasses. view edgesFrom: #superclass. view treeLayout."-------------" "-------------" "Below is the initiation of the menu and opening the visualization" ROEaselMorphic new populateMenuOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<Screen Shot 2013-06-17 at 9.28.21 AM.png>
Alexandre
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Stupid problem it was. The ROView object keeps a list of elements that are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it. However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
> Hi, > to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes. > > The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse. > > So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. > Cheers, > Fabrizio > > > 2013/6/8 Tudor Girba tudor@tudorgirba.com > n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well? > > Doru > > > On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote: > >> Hi Mathieu, >> >> We will have a look at this asap >> >> Alexandre >> >> >> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote: >> >>> Hi >>> >>> I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better). >>> >>> Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes. >>> >>> >>> Regards >>> >>> Mathieu >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
tx Alex. Its working ;).
On Mon, Jun 17, 2013 at 9:44 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Here is a solution:
| browser | browser := GLMTabulator new. browser column: #list; column: #drawing.
browser transmit to: #list; andShow: [ :a | a list ]. browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | | m | m := ROMiniMap new. moview raw @ m. collection do: [ :x | moview view add: (ROElement spriteOn: x) + ROLabel + ROBox white ]. ROVerticalLineLayout on: moview view elements.
moview addMenu: 'map' callBack: [ :viewStack | m openMiniMapFor: viewStack ]. ] ].browser openOn: #(1 2 3 4 5 6).
Probably not ideal, but it seems to do what you may need.
Cheers, Alexandre
On Jun 17, 2013, at 12:34 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
Alex, Probably its the way keyboard shortcuts are handled in Glamour. ========================================================== This is not working:
| browser viewHack | browser := GLMTabulator new. browser column: #list; column: #drawing.
browser transmit to: #list; andShow: [ :a | a list ]. browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | moview raw @ (ROMiniMap new targetView: moview stack). collection do: [ :x | moview view add: (ROElement
spriteOn: x) + ROLabel + ROBox white ].
ROVerticalLineLayout on: moview view elements. viewHack := moview view. ] ].browser openOn: #(1 2 3 4 5 6).
====================================================================== But this does: | browser viewHack | browser := GLMTabulator new. browser column: #drawing.
browser transmit to: #drawing; andShow: [ :a | a roassal painting: [ :moview :collection | moview raw @ (ROMiniMap new targetView: moview stack). collection do: [ :x | moview view add: (ROElement
spriteOn: x) + ROLabel + ROBox white ].
ROVerticalLineLayout on: moview view elements. viewHack := moview view. ] ].browser openOn: #(1 2 3 4 5 6).
So may be we need to invoke the mini map without keyboard shortcuts.
usman
On Mon, Jun 17, 2013 at 5:23 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Why is this not working? Can you give a complete script that we can start from?
Cheers, Alexandre
On Jun 17, 2013, at 10:47 AM, Usman Bhatti usman.bhatti@gmail.com
wrote:
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
I just tried it out at now it is definetly faster. It is fast enough
to be usable. The dragging is still a bit slow but that matter of seconds not minutes as before. Would it be possible to have a scrollable visualization instead of a draggable one?
Having scrollbars is on our todos for a long time. Juraj will
implement one on some point.
In the meantime, have you tried the minimap? This is pretty cool.
Yes it is. MiniMap is not working in Glamour-Roassal, so if someone
can have a look, it'll be great.
Doit the following and press the key m:
"Source code: ROMondrianExample>>miniMapOn:" "Preambule. It includes the initialization. " | view rawView | rawView := ROView new. view := ROMondrianViewBuilder view: rawView. "-------------" "-------------"
view raw @ (ROMiniMap new targetView: view stack). "press m to open the view minimap " view shape rectangle width: [ :cls | cls numberOfVariables * 5 ]; height: #numberOfMethods; linearFillColor: #numberOfLinesOfCode within:Collection withAllSubclasses.
view interaction popupText: [ :cls | cls name, (String with: Character cr), cls methods size printString, ' methods', (String with:Character cr),
cls instVarNames size printString, ' variables', (Stringwith: Character cr),
cls numberOfLinesOfCode printString, ' LOC' ]. view interaction action: #browse. view nodes: Collection withAllSubclasses. view edgesFrom: #superclass. view treeLayout."-------------" "-------------" "Below is the initiation of the menu and opening the visualization" ROEaselMorphic new populateMenuOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<Screen Shot 2013-06-17 at 9.28.21 AM.png>
Alexandre
Cheers, Fabrizio
2013/6/16 Stéphane Ducasse Stephane.Ducasse@inria.fr
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Stupid problem it was. The ROView object keeps a list of elements
that are visible within the window. In the drawing loop, the view iterates over each elements and check if the element is visible before drawing it.
However this is completely unnecessary.
why? because when you explain it it looks something smart to do :)
But there are still some optimizations to be done
Alexandre
On Jun 15, 2013, at 2:36 PM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
Alex
What was the problem?
Stef On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
> Hi Fabrizio, > > Can you try again? > It should be significantly faster, even though we are still
rendering elements that are not visible.
> > Cheers, > Alexandre > > > On Jun 14, 2013, at 5:41 AM, Fabrizio Perin <
fabrizio.perin@gmail.com> wrote:
> >> Hi, >> to have fast algorithms to layout the elements is very good, but
a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
>> >> The same visulization opened with a MOViewRenderer was nice and
easy to interact with and to browse.
>> >> So, my point is that the priority is absolutly to make roassal
more scalable in term of interaction and not in term of initial rendering.
>> Cheers, >> Fabrizio >> >> >> 2013/6/8 Tudor Girba tudor@tudorgirba.com >> n log(n) sounds quite good for this kind of algorithm. But, what
does n mean? Is it the amount of nodes, or the amount of edges as well?
>> >> Doru >> >> >> On Jun 7, 2013, at 6:18 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
>> >>> Hi Mathieu, >>> >>> We will have a look at this asap >>> >>> Alexandre >>> >>> >>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote: >>> >>>> Hi >>>> >>>> I've made some tests on the force based layout, and it seems
it has really a complexity in nlog(n) (and we cannot do really better).
>>>> >>>> Thus when you take 3 seconds to compute a layout with 100
nodes, then it's normal to take 40 seconds with 1000 nodes.
>>>> >>>> >>>> Regards >>>> >>>> Mathieu >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex, thanks really a lot, i didn't expect a so fast answer, mine was more a suggestion :)
Anyway tomorrow at work I will be able to access again to the model I was using and I will let you know about the performances.
Cheers, Fabrizio
2013/6/14 Alexandre Bergel alexandre.bergel@me.com
Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a
visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to
interact with and to browse.
So, my point is that the priority is absolutly to make roassal more
scalable in term of interaction and not in term of initial rendering.
Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n
mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has
really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then
it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
yes, let us know
Alexandre
On Jun 16, 2013, at 6:08 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi Alex, thanks really a lot, i didn't expect a so fast answer, mine was more a suggestion :)
Anyway tomorrow at work I will be able to access again to the model I was using and I will let you know about the performances.
Cheers, Fabrizio
2013/6/14 Alexandre Bergel alexandre.bergel@me.com Hi Fabrizio,
Can you try again? It should be significantly faster, even though we are still rendering elements that are not visible.
Cheers, Alexandre
On Jun 14, 2013, at 5:41 AM, Fabrizio Perin fabrizio.perin@gmail.com wrote:
Hi, to have fast algorithms to layout the elements is very good, but a visualization that opens in 1 second but that I cannot touch is useless. I tried to open a name cloud visualization on a group with 21300 elements, the visulization take just few seconds to open up but than even to display a popup window with a mouse over an element take seconds. Not to mention that I cannot scroll the view or I have to wait minutes sometimes.
The same visulization opened with a MOViewRenderer was nice and easy to interact with and to browse.
So, my point is that the priority is absolutly to make roassal more scalable in term of interaction and not in term of initial rendering. Cheers, Fabrizio
2013/6/8 Tudor Girba tudor@tudorgirba.com n log(n) sounds quite good for this kind of algorithm. But, what does n mean? Is it the amount of nodes, or the amount of edges as well?
Doru
On Jun 7, 2013, at 6:18 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck@mailoo.org wrote:
Hi
I've made some tests on the force based layout, and it seems it has really a complexity in nlog(n) (and we cannot do really better).
Thus when you take 3 seconds to compute a layout with 100 nodes, then it's normal to take 40 seconds with 1000 nodes.
Regards
Mathieu
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I am not sure event generation is the only thing we would like to concentrate during the GSOC because there can be other optimizations. The thing is that the current work is as interesting as improving the performance of Roassal. But we'll have to set priorities at the end we might not have enough time to profile and improve all the points impacting the performance in Roassal.
The event generation may be closely linked to the poor performance of Roassal. Events are generated all the time, as soon as you move the mouse without doing anything. This is not something we should remove, however this is something we should think carefully.
For now, the idea is to make sure that what Mathieu has done so far with his layouts is not lost but integrated in Roassal. Then, the next move can concentrate on integrating Athens better since Mathieu is physically close to Igor.
Cheers, Alexandre
I'm sorry may be I'm too dull but I did not understand the plan for the GSOC of Matthieu. Igor told us a while ago that athens offers transformation matrix that could really speed up Roassal.
The idea is indeed to replace the way coordinate are computed in Roassal by using Matrixes. And Athens will play an important role. It may speed up the visualization.
Now is there a plan to use that in Roassal? If Roassal should stay platform independent then there should be a solution at its architectural level to have one library for Athens and one for the rest.
Yes there is a plan, and the idea is that Matthieu will work on it as soon as possible. Having Athens matrixes in Roassal has nothing to do with Roassal being platform independent.
In addition I do not understand how Roassal can work fast on amber while using Athens without again using the athens infrastructure.
For Amber, we still unsure about the strategy to adopt here.
Alexandre
-
Alexandre Bergel -
Fabrizio Perin -
mathieubmddehouck＠mailoo.org -
Stéphane Ducasse -
Stéphane Ducasse
-
Tudor Girba -
Usman Bhatti -
Vanessa Peña Araya