5 Jun
2013
5 Jun
'13
7:52 a.m.
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
5 Jun
5 Jun
10:06 a.m.
+1 :-)
On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr>wrote;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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:45 p.m.
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(a)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(a)iam.unibe.ch <mailto:Moose-dev@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
9:54 p.m.
On Jun 5, 2013, at 9:45 PM, Vanessa Peña Araya <van.c.pena(a)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(a)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(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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
6 Jun
6 Jun
3:47 p.m.
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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev +1 :-)
On Wed, Jun 5, 2013 at 7:52 AM, Stéphane Ducasse <stephane.ducasse(a)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(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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:04 a.m.
On Wed, Jun 5, 2013 at 9:45 PM, Vanessa Peña Araya <van.c.pena(a)gmail.com>wrote;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.
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(a)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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:24 p.m.
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
2:27 p.m.
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
3:41 p.m.
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
4:36 p.m.
Le 06.06.2013 15:41, Alexandre Bergel a écrit :
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
> 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.
7 Jun
7 Jun
3:19 p.m.
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
6:18 p.m.
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 Jun
8 Jun
11:49 p.m.
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(a)me.com> wrote:
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)mailoo.org wrote:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
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(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 
14 Jun
14 Jun
11:41 a.m.
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(a)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(a)me.com>
wrote:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
5:46 p.m.
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(a)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(a)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(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)mailoo.org wrote:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
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 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(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
6:30 p.m.
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(a)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(a)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(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)mailoo.org wrote:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
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 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(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
15 Jun
15 Jun
8:36 p.m.
Alex
What was the problem?
Stef
On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)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(a)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(a)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(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)mailoo.org wrote:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
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 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(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
16 Jun
16 Jun
5:12 p.m.
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(a)inria.fr> wrote:
Alex
What was the problem?
Stef
On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)gmail.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
"We cannot reach the flow of things unless we let go."
_______________________________________________
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
7:20 p.m.
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)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(a)inria.fr> wrote:
Alex
What was the problem?
Stef
On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 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(a)gmail.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)me.com> wrote:
> Hi Mathieu,
>
> We will have a look at this asap
>
> Alexandre
>
>
> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
"We cannot reach the flow of things unless we let go."
_______________________________________________
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
17 Jun
17 Jun
8:28 a.m.
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(a)inria.fr>
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
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(a)inria.fr>
wrote:
> Alex
>
> What was the problem?
>
> Stef
> On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)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(a)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(a)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(a)me.com>
wrote:
>>>
>>>> Hi Mathieu,
>>>>
>>>> We will have a look at this asap
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>
> "We cannot reach the flow of things unless we let go."
>
>
>
>
> _______________________________________________
> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:04 a.m.
On Mon, Jun 17, 2013 at 8:28 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com>wrote;wrote:
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(a)inria.fr>
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
_______________________________________________
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
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(a)inria.fr>
wrote:
> Alex
>
> What was the problem?
>
> Stef
> On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)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(a)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(a)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(a)me.com> wrote:
>>>
>>>> Hi Mathieu,
>>>>
>>>> We will have a look at this asap
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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
3:28 p.m.
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(a)inria.fr>
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)inria.fr> wrote:
_______________________________________________
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 Alex
What was the problem?
Stef
On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 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(a)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(a)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(a)me.com> wrote:
>
>> Hi Mathieu,
>>
>> We will have a look at this asap
>>
>> Alexandre
>>
>>
>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>
> "We cannot reach the flow of things unless we let go."
>
>
>
>
> _______________________________________________
> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
4:47 p.m.
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexandre
Cheers,
Fabrizio
2013/6/16 Stéphane Ducasse <Stephane.Ducasse(a)inria.fr>
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
_______________________________________________
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
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(a)inria.fr>
wrote:
> Alex
>
> What was the problem?
>
> Stef
> On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)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(a)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(a)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(a)me.com>
wrote:
>>>
>>>> Hi Mathieu,
>>>>
>>>> We will have a look at this asap
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>
> "We cannot reach the flow of things unless we let go."
>
>
>
>
> _______________________________________________
> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
5:23 p.m.
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(a)gmail.com> wrote:
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)inria.fr>
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 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(a)inria.fr> wrote:
_______________________________________________
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 Alex
What was the problem?
Stef
On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)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(a)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(a)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(a)me.com>
wrote:
>>
>>> Hi Mathieu,
>>>
>>> We will have a look at this asap
>>>
>>> Alexandre
>>>
>>>
>>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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
6:34 p.m.
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(a)me.com>wrote;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(a)gmail.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel <
alexandre.bergel(a)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(a)inria.fr>
>
> On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)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(a)inria.fr> wrote:
> >
> >> Alex
> >>
> >> What was the problem?
> >>
> >> Stef
> >> On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <
alexandre.bergel(a)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(a)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(a)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(a)me.com> wrote:
> >>>>
> >>>>> Hi Mathieu,
> >>>>>
> >>>>> We will have a look at this asap
> >>>>>
> >>>>> Alexandre
> >>>>>
> >>>>>
> >>>>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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
_______________________________________________
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
9:44 p.m.
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(a)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(a)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(a)gmail.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 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(a)inria.fr>
On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 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(a)inria.fr> wrote:
> Alex
>
> What was the problem?
>
> Stef
> On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <alexandre.bergel(a)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(a)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(a)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(a)me.com>
wrote:
>>>
>>>> Hi Mathieu,
>>>>
>>>> We will have a look at this asap
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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
_______________________________________________
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
20 Jun
20 Jun
1:20 p.m.
tx Alex.
Its working ;).
On Mon, Jun 17, 2013 at 9:44 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;wrote:
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(a)gmail.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
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(a)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(a)gmail.com>
wrote:
>
>
>
> On Mon, Jun 17, 2013 at 3:28 PM, Alexandre Bergel <
alexandre.bergel(a)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(a)inria.fr>
>>
>> On Jun 16, 2013, at 5:12 PM, Alexandre Bergel <
alexandre.bergel(a)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(a)inria.fr> wrote:
>> >
>> >> Alex
>> >>
>> >> What was the problem?
>> >>
>> >> Stef
>> >> On Jun 14, 2013, at 6:30 PM, Alexandre Bergel <
alexandre.bergel(a)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(a)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(a)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(a)me.com> wrote:
>> >>>>
>> >>>>> Hi Mathieu,
>> >>>>>
>> >>>>> We will have a look at this asap
>> >>>>>
>> >>>>> Alexandre
>> >>>>>
>> >>>>>
>> >>>>> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
>>>>
>>>> "We cannot reach the flow of things unless we let go."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
16 Jun
16 Jun
12:08 p.m.
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(a)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(a)gmail.com>
wrote:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
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
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(a)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(a)me.com>
wrote:
> Hi Mathieu,
>
> We will have a look at this asap
>
> Alexandre
>
>
> On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)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(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
5:13 p.m.
yes, let us know
Alexandre
On Jun 16, 2013, at 6:08 AM, Fabrizio Perin <fabrizio.perin(a)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(a)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(a)gmail.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)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(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 Hi Mathieu,
We will have a look at this asap
Alexandre
On Jun 7, 2013, at 9:19 AM, mathieubmddehouck(a)mailoo.org wrote:
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
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 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(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
6 Jun
6 Jun
3:45 p.m.
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
3:34 p.m.
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 http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
4251
days inactive
4266
days old
30 comments
8 participants
participants (8)
-
Alexandre Bergel -
Fabrizio Perin -
mathieubmddehouck＠mailoo.org -
Stéphane Ducasse -
Stéphane Ducasse
-
Tudor Girba -
Usman Bhatti -
Vanessa Peña Araya