4 May
2013
4 May
'13
9:52 a.m.
Hi guys
with igor we sat and had a look at Roassal for a couple of minutes and here are a list of
points for real speed improvements.
Igor did not want to send them because he does not want to look like an asshole
criticizing but I think that if we want roassal to be really
a success we should.
Now are the mooser and roassalers really interested in making Roassal scalable? (I hope so
but I would respect otherwise and think for the future :)
because we (moosers) could ask for feedback to igor and Alex you could come to pair
program here with him around ESUG.
Stef
* Point 1: wasting cycles to do conversion
--------------------------------------------------------
ROPharoCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor
nativeCanvas line: (self virtualToRealPoint: aPoint) to: (self virtualToRealPoint:
aPoint2) width: aSmallInteger color: aColor.
wasting cycles to convert from your local coordinate space into global one on every single
operation is not a good idea. Guess why :)
Athens provides the user-space coordinate system for geometry by default.. so that you
don't have to maintain it by yourself.
So if you want a real system these points should be addressed ;)
* Point 2: missing transformation matrix
-----------------------------------------------------
You don't even have a transformation as a concept.. and instead of simple and
straightforward affine matrix which people
learn in schools today: a Camera
virtualToRealPointNoTrunc: aPoint
"Return a virtual point from a one expressed in the real coordinates"
| visibleBounds offset |
visibleBounds := self bounds.
offset := self position.
^ ((aPoint x asFloat - offset x * realExtent x / visibleBounds width) asFloat) @
((aPoint y asFloat - offset y * realExtent y / visibleBounds height) asFloat)
ROAthensCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor
| path |
path := nativeCanvas createPath: [:builder |
builder
absolute;
moveTo: (self virtualToRealPoint: aPoint);
lineTo: (self virtualToRealPoint: aPoint2).
].
(nativeCanvas setStrokePaint: aColor) width: aSmallInteger .
nativeCanvas drawShape: path
see this #virtualToRealPoint: calls?
Athens provides this for free. Do not do it the hard way: (do not transform poor vector
multiple times to get there.)
Athens do it for you using math:
(v * M1) * M2 = v * (M1*M2)
* Point 3 about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
6 May
6 May
1:26 p.m.
New subject: About roassal design points for scalability if it will use athens for real
Igor did not want to send them because he does not
want to look like an asshole criticizing but I think that if we want roassal to be really
a success we should.
Sure, making this email public is the best to do. As researchers we should embrace
feedback, even if not positive.
* Point 1: wasting cycles to do conversion
--------------------------------------------------------
ROPharoCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor
nativeCanvas line: (self virtualToRealPoint: aPoint) to: (self virtualToRealPoint:
aPoint2) width: aSmallInteger color: aColor.
wasting cycles to convert from your local coordinate space into global one on every
single operation is not a good idea. Guess why :)
Athens provides the user-space coordinate system for geometry by default.. so that you
don't have to maintain it by yourself.
So if you want a real system these points should be addressed ;)
Maintaining virtual coordinates is essential for zooming and scrolling the whole view.
Athens has indeed fast primitives to do this. We will probably consider using them this
once Athens will be part of Pharo.
* Point 2: missing transformation matrix
-----------------------------------------------------
You don't even have a transformation as a concept.. and instead of simple and
straightforward affine matrix which people
learn in schools today: a Camera
[ ... ]
see this #virtualToRealPoint: calls?
Athens provides this for free. Do not do it the hard way: (do not transform poor vector
multiple times to get there.)
Athens do it for you using math:
(v * M1) * M2 = v * (M1*M2)
We thought about using matrixes. And the nice things is to be able to do rotation, thing
that we cannot do right now in Roassal because we do not have matrixes. We are wondering
whether we should wait for Athens to be part of Roassal to use matrix or doing it our
way.
By the way, using a matrix implies more operations that Roassal actually does, because
doing v * M has more operations than the method #virtualToRealPoint:. However this does
not really matter since this is rather cheap.
* Point 3 about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
3:07 p.m.
New subject: About roassal design points for scalability if it will use athens for real
On 6 May 2013 13:26, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
are you sure that v*M has more operations?
AtthensAffineTransform>>transform: aPoint
| px py |
px := aPoint x.
py := aPoint y.
^ Point
x: (sx*px +(shx*py) + x)
y: (shy*px + (sy*py) + y)
4 multiplications 4 additions
virtualToRealPointNoTrunc: aPoint
"Return a virtual point from a one expressed in the real coordinates"
| visibleBounds offset |
visibleBounds := self bounds.
offset := self position.
^ ((aPoint x asFloat - offset x * realExtent x / visibleBounds
width) asFloat) @
((aPoint y asFloat - offset y * realExtent y / visibleBounds
height) asFloat)
2 subtractions
2 muls
2 divisions
+ float conversions (why they are there?)
+ converting back to integers
virtualToRealPoint: aPoint
"Return a virtual point from a one expressed in the real coordinates"
^ (self virtualToRealPointNoTrunc: aPoint) asIntegerPoint
+ adding extra point in ROAbstractCanvas (2 additions more)
virtualToRealPoint: aPoint
"Return a real point from a one expressed in the virtual coordinates"
^ (camera virtualToRealPoint: aPoint) + offset
And things like:
virtualToRealRectangle: aRectangle
"Return a rectangle with real coordinates from one expressed in the
virtual coordinates"
^ (self virtualToRealPoint: aRectangle origin) corner: (self
virtualToRealPoint: aRectangle corner)
this makes sense only if both coordinate systems not rotated
respective to each other.
Once you have rotation, this method loses all geometrical sense and
very dangerous to use.
no, i was wondering why you need more than a single class,
representing an arrow which
connects two arbitrary points. Instead you have only horizontal or
vertical + separate subclasses for
different arrow direction..
so, either i don't understand something, or if i right, this needs to
be thrown away.
Igor did not
want to send them because he does not want to look like an asshole criticizing but I think
that if we want roassal to be really
a success we should.
Sure, making this email public is the best to do. As researchers we should embrace
feedback, even if not positive.
* Point 1: wasting cycles to do conversion
--------------------------------------------------------
ROPharoCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor
nativeCanvas line: (self virtualToRealPoint: aPoint) to: (self virtualToRealPoint:
aPoint2) width: aSmallInteger color: aColor.
wasting cycles to convert from your local coordinate space into global one on every
single operation is not a good idea. Guess why :)
Athens provides the user-space coordinate system for geometry by default.. so that you
don't have to maintain it by yourself.
So if you want a real system these points should be addressed ;)
Maintaining virtual coordinates is essential for zooming and scrolling the whole view.
Athens has indeed fast primitives to do this. We will probably consider using them this
once Athens will be part of Pharo.
* Point 2: missing transformation matrix
-----------------------------------------------------
You don't even have a transformation as a concept.. and instead of simple and
straightforward affine matrix which people
learn in schools today: a Camera
[ ... ]
see this #virtualToRealPoint: calls?
Athens provides this for free. Do not do it the hard way: (do not transform poor vector
multiple times to get there.)
Athens do it for you using math:
(v * M1) * M2 = v * (M1*M2)
We thought about using matrixes. And the nice things is to be able to do rotation, thing
that we cannot do right now in Roassal because we do not have matrixes. We are wondering
whether we should wait for Athens to be part of Roassal to use matrix or doing it our
way.
By the way, using a matrix implies more operations that Roassal actually does, because
doing v * M has more operations than the method #virtualToRealPoint:. However this does
not really matter since this is rather cheap.
* Point 3
about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Best regards,
Igor Stasenko.
3:21 p.m.
New subject: About roassal design points for scalability if it will use athens for real
are you sure that v*M has more operations?
Your matrixes are 2x2 ? I thought they would be 3x3, I haven't verified, by having 3x3
for 2d plans allows for zooming. But maybe you do not need since Athens handles this
apart.
AtthensAffineTransform>>transform: aPoint
[ ... ]
4 multiplications 4 additions
Do you call #transform: just once per object?
Roassal supports nesting of elements. So I guess you need at least two #transform:, one of
the translation to the inner scope, and another for the global transformation.
this makes sense only if both coordinate systems not
rotated
respective to each other.
Once you have rotation, this method loses all geometrical sense and
very dangerous to use.
Yes, this does not work for rotation.
* Point 3 about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
3:53 p.m.
New subject: About roassal design points for scalability if it will use athens for real
On 6 May 2013 15:21, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
that's not the point. The point is that the user-to-screen space
transformation is given by Athens.
(actually it is maintained by backend directly, and transformation
happens only when necessary during rendering cycle
by graphics engine itself). A user is free to use any coordinate
system he wants and don't need to convert them manually,
he just needs to use transformation he desiring, and draw all geometry
using own coordinates.
Needless to say, that computations at primitive level is much more
efficient than at smalltalk level.
For having nested (hierarchical) transformations , you just modify the
matrix (once), when you go into one level deeper.
So, you still have result := v*M
instead of calculating result := v*M1*M2
no, i was wondering why you need more than a single class,
representing an arrow which
connects two arbitrary points. Instead you have only horizontal or
vertical + separate subclasses for
different arrow direction..
so, either i don't understand something, or if i right, this needs to
be thrown away.
How could it be kept modular and simple if this is not by having subclasses?
How does this related to modularity?
Or.. you think it will be more modular, if you introduce "DiagonalArrow"..
and then since it can be drawn in 4 quadrants, you will need
DiagonalArrow1stQuadrant
DiagonalArrow2ndQuadrant
DiagonalArrow3rdtQuadrant
DiagonalArrow4thtQuadrant
and since you need reverse, you will need
DiagonalArrow1stQuadrantReversed
DiagonalArrow2ndQuadrantReversed
DiagonalArrow3rdtQuadrantReversed
DiagonalArrow4thtQuadrantReversed
?
You still don't see that there's something wrong with approach?
are you sure
that v*M has more operations?
Your matrixes are 2x2 ? I thought they would be 3x3, I haven't verified, by having
3x3 for 2d plans allows for zooming. But maybe you do not need since Athens handles this
apart.
AtthensAffineTransform>>transform: aPoint
[ ... ]
4 multiplications 4 additions
Do you call #transform: just once per object?
Roassal supports nesting of elements. So I guess you need at least two #transform:, one
of the translation to the inner scope, and another for the global transformation.
this makes
sense only if both coordinate systems not rotated
respective to each other.
Once you have rotation, this method loses all geometrical sense and
very dangerous to use.
Yes, this does not work for rotation.
* Point 3 about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
Having symbols such as #orientation and a boolean
reversed?
Why you need orientation flag? The arrow direction can be defined by
order of points which you passing to it.
If you swap order, you will swap direction. And no need for flag.
Simple , isn't?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Best regards,
Igor Stasenko.
4:16 p.m.
New subject: About roassal design points for scalability if it will use athens for real
9:13 p.m.
New subject: About roassal design points for scalability if it will use athens for real
I had some passing thoughts about Arrow hierarchy
along the lines of... (from memory a while ago...)
* ROArrow is normally associated with a single ROLine between two points, and is oriented
to the direction of that line based on the line end points.
* ROOrthoVerticalLineShape & ROOrthoHorizontalLineShape were introduced, made up of
three segments, but ROArrow looked skewed since it was still drawn relative to the two end
points.
* ROHorizontalArrow and ROVerticalArrow were added make nice arrows for the Ortho-Lines,
however over time I started thinking these might be eliminated it ROArrow could be drawn
relative to the end-point of each end-segment, rather than the end points of the overall
line. ...but I hadn't had a chance to look into that further.
Yes, you're right. ROHorizontalArrow and ROVerticalArrow should probably be eliminated
if edges are better handled.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
6:30 p.m.
New subject: About roassal design points for scalability if it will use athens for real
On May 6, 2013, at 3:21 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
did you try the code snippet of igor that I sent to the list?
Because you can zoom in a vector graphics polymetric view.
no, i was wondering why you need more than a single class,
representing an arrow which
connects two arbitrary points. Instead you have only horizontal or
vertical + separate subclasses for
different arrow direction..
so, either i don't understand something, or if i right, this needs to
be thrown away.
How could it be kept modular and simple if this is not by having subclasses?
Having symbols such as #orientation and a boolean reversed?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
are you sure
that v*M has more operations?
Your matrixes are 2x2 ? I thought they would be 3x3, I haven't verified, by having
3x3 for 2d plans allows for zooming. But maybe you do not need since Athens handles this
apart.
AtthensAffineTransform>>transform: aPoint
[ ... ]
4 multiplications 4 additions
Do you call #transform: just once per object?
Roassal supports nesting of elements. So I guess you need at least two #transform:, one
of the translation to the inner scope, and another for the global transformation.
this makes sense only if both coordinate systems
not rotated
respective to each other.
Once you have rotation, this method loses all geometrical sense and
very dangerous to use.
Yes, this does not work for rotation.
* Point 3 about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
8 May
8 May
10:19 p.m.
New subject: About roassal design points for scalability if it will use athens for real
Your matrixes
are 2x2 ? I thought they would be 3x3, I haven't verified, by having 3x3 for 2d plans
allows for zooming. But maybe you do not need since Athens handles this apart.
did you try the code snippet of igor that I sent to the list?
Because you can zoom in a vector graphics polymetric view.
9 May
9 May
1:59 a.m.
New subject: About roassal design points for scalability if it will use athens for real
On 8 May 2013 22:19, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
But don't be fooled by concrete (AthensAffineTransform) matrix.
In reality, Athens works with abstract "transform" object (AthensTransform)
i.e.
canvas pathTransform
or
canvas paintTransform
and while under the hood, things are run by matrices, i really
discourage you from
betting what kind of data they hold, and either they are 2x3 , 3x3 of
4x4 matrices.
This is backend-specific and not of your concern.
For that reason, the API prohibits you from directly accessing the
matrix state (i.e. get/set value at rowN columnM).
Instead there's operators (methods) which modifying transform e.g.
canvas pathTransform scaleBy:2
means that for all subsequent operations
canvas pathTransform will become the result of: (current canvas
pathTransform * scale matrix)
same for the rest operations.
For more details, look at AthensTransform class comment. It is a bit
outdated, but you will get an idea.
>> Your matrixes are 2x2 ? I thought they would
be 3x3, I haven't verified, by having 3x3 for 2d plans allows for zooming. But maybe
you do not need since Athens handles this apart.
>
well, matrix in athens is 2x3 affine matrix.
(consider it is like a full 3x3 matrix but with all zeros at bottom row)
simply because if you extend 2d vector to 3d, you put z-component to 0..
that means , if you multiply such vector with full 3x3 matrix,
the 3rd row will be completely ignored, because z-component does not
contributes to
x and y coordinates.
did you try
the code snippet of igor that I sent to the list?
Because you can zoom in a vector graphics polymetric view.
Well, I had a look at the code. The matrix of Athens are indeed small and neat.
Replacing this in Roassal is not trivial and cannot be done in a matter of a few
minutes.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
Best regards,
Igor Stasenko.
4:31 a.m.
New subject: About roassal design points for scalability if it will use athens for real
On 9 May 2013 01:59, Igor Stasenko <siguctua(a)gmail.com> wrote:
On 8 May 2013 22:19, Alexandre Bergel
<alexandre.bergel(a)me.com> wrote:
actually to be more correct,
affine matrix is 3x3 , with bottom row = (0 0 1)
and 2d vector is assumed to have z=1
like that if you multiply vector by such matrix, z coordinate always
stays = 1 (identity)
while 3rd column of matrix contributes to linear translation in XY plane.
so, since bottom row is always the same (as well as z-coordinate of
extended 2d vector)
they are not needed to be stored as data.
yeah, and the key property of affine matrix that transformation stays
linear, no matter what
e.g. that you can decompose it into 3 simple parts: scale(can be
non-uniform), rotation and translation.
Therefore a non-linear transformation (like perspective projection) is
not possible since it will require higher order matrix (like 4x4 used
by OpenGL) to get 1 more degree of freedom.
--
Best regards,
Igor Stasenko.
>> Your matrixes are 2x2 ? I thought they
would be 3x3, I haven't verified, by having 3x3 for 2d plans allows for zooming. But
maybe you do not need since Athens handles this apart.
>
well, matrix in athens is 2x3 affine matrix.
(consider it is like a full 3x3 matrix but with all zeros at bottom row)
simply because if you extend 2d vector to 3d, you put z-component to 0..
that means , if you multiply such vector with full 3x3 matrix,
the 3rd row will be completely ignored, because z-component does not
contributes to
x and y coordinates.
6 May
6 May
6:28 p.m.
New subject: About roassal design points for scalability if it will use athens for real
* Point 1: wasting cycles to do conversion
--------------------------------------------------------
ROPharoCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor
nativeCanvas line: (self virtualToRealPoint: aPoint) to: (self virtualToRealPoint:
aPoint2) width: aSmallInteger color: aColor.
wasting cycles to convert from your local coordinate space into global one on every
single operation is not a good idea. Guess why :)
Athens provides the user-space coordinate system for geometry by default.. so that you
don't have to maintain it by yourself.
So if you want a real system these points should be addressed ;)
Maintaining virtual coordinates is essential for zooming and scrolling the whole view.
Athens has indeed fast primitives to do this. We will
probably consider using them this once Athens will be part of Pharo.
I do not understand why you insist on saying that.
Even if Athens would not be part of Pharo Moose should use it!
I do not get why you want to wait that 3.0 is out. Because may be we should all wait that
igor leave RMoD do give him feedback.
Right now Athens takes 2 lines to load in Pharo3.0.
* Point 2:
missing transformation matrix
-----------------------------------------------------
You don't even have a transformation as a concept.. and instead of simple and
straightforward affine matrix which people
learn in schools today: a Camera
[ ... ]
see this #virtualToRealPoint: calls?
Athens provides this for free. Do not do it the hard way: (do not transform poor vector
multiple times to get there.)
Athens do it for you using math:
(v * M1) * M2 = v * (M1*M2)
We thought about using matrixes. And the nice things is to be able to do rotation, thing
that we cannot do right now in Roassal because we do not have matrixes. We are wondering
whether we should wait for Athens to be part of Roassal to use matrix or doing it our way.
By the way, using a matrix implies more operations
that Roassal actually does, because doing v * M has more operations than the method
#virtualToRealPoint:. However this does not really matter since this is rather cheap.
But your code in virtualToRealPoint: is not efficient: / float conversion….
then rounding it and then adding int.
* Point 3
about design
------------------------------
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:50 p.m.
New subject: About roassal design points for scalability if it will use athens for real
On 6 May 2013 18:28, stephane ducasse <stephane.ducasse(a)free.fr> wrote:
? I do not get why.
Yes, having more real users of Athens is really good from all sides of
view: it will help a lot
for polishing and delivering quality. And making sure that Athens
suits your needs.
Because if you wait until "final & golden" version will be released,
you may discover that
it is quite far from your interpretation of what "golden" is.. and to
ensure that it is the same,
the best way is to participate and give feedback.
* Point 1: wasting cycles to do conversion
--------------------------------------------------------
ROPharoCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor
nativeCanvas line: (self virtualToRealPoint: aPoint) to: (self virtualToRealPoint:
aPoint2) width: aSmallInteger color: aColor.
wasting cycles to convert from your local coordinate space into global one on every
single operation is not a good idea. Guess why :)
Athens provides the user-space coordinate system for geometry by default.. so that you
don't have to maintain it by yourself.
So if you want a real system these points should be addressed ;)
Maintaining virtual coordinates is essential for zooming and scrolling the whole view.
Athens has indeed fast primitives to do this. We
will probably consider using them this once Athens will be part of Pharo.
I do not understand why you insist on saying that.
Even if Athens would not be part of Pharo Moose should use it!
I do not get why you want to wait that 3.0 is out. Because may be we should all wait that
igor leave RMoD do give him feedback.
Right now Athens takes 2 lines to load in Pharo3.0.
Use Athens because igor is much better than us on vector graphics and Athens has all
that.
I'm not better than anyone else who can do linear algebra. The math
involved there is
very simple.. no rockets , no science. Yes, i learned a lot about
different stuff..
but i am not inventing anything new.. Athens is about bringing
_existing_ tech into our little world.
And all information is available on web, in dozens forms:
- tutorials, lectures, papers , demos, frameworks, pick yours..
Now, guess , how much time it took me to do what you see on screenshot?
--
Best regards,
Igor Stasenko.
* Point
2: missing transformation matrix
-----------------------------------------------------
You don't even have a transformation as a concept.. and instead of simple and
straightforward affine matrix which people
learn in schools today: a Camera
[ ... ]
see this #virtualToRealPoint: calls?
Athens provides this for free. Do not do it the hard way: (do not transform poor vector
multiple times to get there.)
Athens do it for you using math:
(v * M1) * M2 = v * (M1*M2)
We thought about using matrixes. And the nice things is to be able to do rotation, thing
that we cannot do right now in Roassal because we do not have matrixes. We are wondering
whether we should wait for Athens to be part of Roassal to use matrix or doing it our way.
9:06 p.m.
New subject: About roassal design points for scalability if it will use athens for real
Yes, having more real users of Athens is really good
from all sides of
view: it will help a lot
for polishing and delivering quality. And making sure that Athens
suits your needs.
Because if you wait until "final & golden" version will be released,
you may discover that
it is quite far from your interpretation of what "golden" is.. and to
ensure that it is the same,
the best way is to participate and give feedback.
I do not really understand why you feel I am reluctant to use Athens. I do use it. My
everyday image is Athens based.
I'm not better than anyone else who can do linear
algebra. The math
involved there is
very simple.. no rockets , no science. Yes, i learned a lot about
different stuff..
but i am not inventing anything new.. Athens is about bringing
_existing_ tech into our little world.
And all information is available on web, in dozens forms:
- tutorials, lectures, papers , demos, frameworks, pick yours..
The part of the Roassal code that do the translation was done way before Athens was
released. So this is not a surprise that Roassal does not use Athens' matrixes...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8:27 p.m.
New subject: About roassal design points for scalability if it will use athens for real
Maintaining
virtual coordinates is essential for zooming and scrolling the whole view.
? I do not get why. Athens has
indeed fast primitives to do this. We will probably consider using them this once Athens
will be part of Pharo.
I do not understand why you insist on saying that. Even if Athens would not be part of Pharo Moose should
use it!
I do not get why you want to wait that 3.0 is out. Because may be we should all wait that
igor leave RMoD do give him feedback.
Right now Athens takes 2 lines to load in Pharo3.0.
We are excited by the perspective to use Athens more. We can now fully rendering using
Athens, without having disrupted our ability to be cross-platform.
We plan to use Athens more, but we cannot "go faster than the music". As fas as
I have seen, Athens is usable since last month, when Igor advertised his tutorial. During
that month we made Roassal perfectly work on Athens. So yes, we will use Athens more, but
we cannot do more than what we are doing right now.
But your code in virtualToRealPoint: is not efficient:
/ float conversion….
then rounding it and then adding int.
I agree this is not optimal. This part of Roassal went through some period of try and
adjust if I remember correctly.
Having a solution based on matrixes is indeed much better.
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo. 
8 May
8 May
10:27 a.m.
New subject: About roassal design points for scalability if it will use athens for real
>
>
Because if there is only one coordinate system, then zooming in and out accumulate
floating point errors.
I am pretty sure Cairo has a translation mechanism under the wood.
Athens
has indeed fast primitives to do this. We will probably consider using them this once
Athens will be part of Pharo.
I do not understand why you insist on saying that. Even if Athens
would not be part of Pharo Moose should use it!
I do not get why you want to wait that 3.0 is out. Because may be we should all wait that
igor leave RMoD do give him feedback.
Right now Athens takes 2 lines to load in Pharo3.0.
We are excited by the perspective to use Athens more. We can now fully rendering using
Athens, without having disrupted our ability to be cross-platform.
We plan to use Athens more, but we cannot "go faster than the music". As fas as
I have seen, Athens is usable since last month, when Igor advertised his tutorial. During that month
we made Roassal perfectly work on Athens. So yes, we will use Athens more, but we cannot
do more than what we are doing right now.
this has nothing to do with traits.
why you do not have
ROArrrow reversed
could probably works.
This is what the hierarchy looks like:
<Screen Shot 2013-05-06 at 2.21.49 PM.png>
This hierarchy is rather stable since nobody asked for more extremity shapes.
Theses classes are very short and easy to understand. Probably code can be refactored out
since they contain duplication. We will work on that on some point.
Yes this is not important
But your code in virtualToRealPoint: is not
efficient: / float conversion….
then rounding it and then adding int.
I agree this is not optimal. This part of Roassal went through some period of try and
adjust if I remember correctly.
Having a solution based on matrixes is indeed much better.
ROAbstractArrow
ROArrow
ROReversedArrow
ROHorizontalArrow
ROReversedHorizontalArrow
ROVerticalArrow
ROReversedVerticalArrow
Why do we have all these classes? why they are not...
... traits? Well... because there is little support in Pharo to work with traits.
Another reason is traits exist only in Pharo.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
6 May
6 May
6:40 p.m.
New subject: About roassal design points for scalability if it will use athens for real
so to come back to my key original question: when will roassal will start to use for real
existing infrastructure?
When do you plan to really have a look and optimise (1) speed and (2) garbage generated?
Alex do you plan to visit us before ESUG?
Stef
9:51 p.m.
New subject: About roassal design points for scalability if it will use athens for real
so to come back to my key original question: when
will roassal will start to use for real existing infrastructure?
:-)
When we will have time and resources. Athens has been in a usable state only until
recently, when Igor made his tutorial.
We are using Athens and we will continue to do so. More and more Athens will become the
base of Roassal. It is just that it takes time.
When do you plan to really have a look and optimise
(1) speed and (2) garbage generated?
Over the last weeks, Roassal went through a major optimization process. Roassal has pretty
much all the optimization that ZVMT has (the library of Emmanuel, from INRIA). More has to
be done I agree.
By the way, if the Synectique crew (or anyone else) find some particular situations that
are judged as too slow, then we will make sure the slowdown get properly removed.
Alex do you plan to visit us before ESUG?
It is still early for me to know. In a couple of weeks I will let you know
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7 May
7 May
9:59 a.m.
New subject: About roassal design points for scalability if it will use athens for real
Hello,
On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:
For the moment, Roassal's performance is better than that of Mondrian and
that suffices us. In the meantime, what we can achieve with Athens are
modern-looking apps. And the screenshots prove that. and If there is a gain
of performance, that's a plus for us so that we prepare ourselves for huge
graphs.
usman
so to come
back to my key original question: when will roassal will
start to use for real
existing infrastructure?
:-)
When we will have time and resources. Athens has been in a usable state
only until recently, when Igor made his tutorial.
We are using Athens and we will continue to do so. More and more Athens
will become the base of Roassal. It is just that it takes time.
When do you plan to really have a look and
optimise (1) speed and (2)
garbage generated?
Over the last weeks, Roassal went through a major optimization process.
Roassal has pretty much all the optimization that ZVMT has (the library of
Emmanuel, from INRIA). More has to be done I agree.
By the way, if the Synectique crew (or anyone else) find some particular
situations that are judged as too slow, then we will make sure the slowdown
get properly removed.
Alex do you plan to visit us before ESUG?
It is still early for me to know. In a couple of weeks I will let you know
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:43 a.m.
New subject: About roassal design points for scalability if it will use athens for real
On May 7, 2013, at 9:59 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
Hello,
On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
the problem with huge graph is that you get lost.
We should just use them to bench roassal.
so to come back to my key original question:
when will roassal will start to use for real existing infrastructure?
:-)
When we will have time and resources. Athens has been in a usable state only until
recently, when Igor made his tutorial.
We are using Athens and we will continue to do so. More and more Athens will become the
base of Roassal. It is just that it takes time.
When do you plan to really have a look and
optimise (1) speed and (2) garbage generated?
Over the last weeks, Roassal went through a major optimization process. Roassal has
pretty much all the optimization that ZVMT has (the library of Emmanuel, from INRIA). More
has to be done I agree.
By the way, if the Synectique crew (or anyone else) find some particular situations that
are judged as too slow, then we will make sure the slowdown get properly removed.
For the moment, Roassal's performance is better than that of Mondrian and that
suffices us. In the meantime, what we can achieve with Athens are modern-looking apps. And
the screenshots prove that. and If there is a gain of performance, that's a plus for
us so that we prepare ourselves for huge graphs.
usman
Alex do you plan to visit us before ESUG?
It is still early for me to know. In a couple of weeks I will let you know
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:57 a.m.
New subject: About roassal design points for scalability if it will use athens for real
On Tue, May 7, 2013 at 10:43 AM, stephane ducasse
<stephane.ducasse(a)free.fr>wrote;wrote:
On May 7, 2013, at 9:59 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
Hello,
On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:
For the moment, Roassal's performance is better than that of Mondrian and
that suffices us. In the meantime, what we can achieve with Athens are
modern-looking apps. And the screenshots prove that. and If there is a gain
of performance, that's a plus for us so that we prepare ourselves for huge
graphs.
the problem with huge graph is that you get lost.
We should just use them to bench roassal.
Yes they are. And then there is also the fact that humans might not be able
to reason about the complex graphs with several thousand nodes. So, I think
in that case we need to understand the use-cases that people may come up
with.
Most of the time, the problem that we are confronted with graphs of
software is to find a tree from a particular node: tracing all the
dependent nodes of a root and ignoring reverse links, if any. That
eliminates a lot of noise. We did some experimentation with Mathieu and we
got simpler, more meaningful radial graphs. I'll try to share images when I
have some time to breath.
usman
so to
come back to my key original question: when will roassal will
start to use for
real existing infrastructure?
:-)
When we will have time and resources. Athens has been in a usable state
only until recently, when Igor made his tutorial.
We are using Athens and we will continue to do so. More and more Athens
will become the base of Roassal. It is just that it takes time.
When do you plan to really have a look and
optimise (1) speed and (2)
garbage generated?
Over the last weeks, Roassal went through a major optimization process.
Roassal has pretty much all the optimization that ZVMT has (the library of
Emmanuel, from INRIA). More has to be done I agree.
By the way, if the Synectique crew (or anyone else) find some particular
situations that are judged as too slow, then we will make sure the slowdown
get properly removed.
usman
_______________________________________________
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 do you plan to visit us before ESUG?
It is still early for me to know. In a couple of weeks I will let you know
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8 May
8 May
10:33 a.m.
New subject: About roassal design points for scalability if it will use athens for real
Yes having some libraries to select down edges and do not display or only when hover
the edges coming back would be good.
Stef
On May 7, 2013, at 10:57 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
Most of the time, the problem that we are confronted with graphs of software is to find a
tree from a particular node: tracing all the dependent nodes of a root and ignoring
reverse links, if any. That eliminates a lot of noise. We did some experimentation with
Mathieu and we got simpler, more meaningful radial graphs. I'll try to share images
when I have some time to breath.
10:15 p.m.
New subject: About roassal design points for scalability if it will use athens for real
A bit of this is possible:
-=-=-=-=-=-=-=-=-=-=
dep := Dictionary new.
dep at: #Layer1 put: #(Layer2 Layer3 Layer5).
dep at: #Layer2 put: #(Layer1 Layer3 Layer4 Layer5).
dep at: #Layer3 put: #(Layer1 Layer2 Layer4 Layer5).
view interaction
dynamicEdgeToAll: [ :model | dep at: model ifAbsent: #() ]
using: (ROLine red).
view shape rectangle withText.
view nodes: #(Layer1 Layer2 Layer3 Layer4 Layer5).
view circleLayout.
-=-=-=-=-=-=-=-=-=-=
My mouse is above Layer1
Alexandre
On May 8, 2013, at 4:33 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote:
Yes having some libraries to select down edges and do
not display or only when hover
the edges coming back would be good.
Stef
On May 7, 2013, at 10:57 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Most of the time, the problem that we are confronted with graphs of software is to find a
tree from a particular node: tracing all the dependent nodes of a root and ignoring
reverse links, if any. That eliminates a lot of noise. We did some experimentation with
Mathieu and we got simpler, more meaningful radial graphs. I'll try to share images
when I have some time to breath.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
7 May
7 May
5:27 p.m.
New subject: About roassal design points for scalability if it will use athens for real
10:42 a.m.
New subject: About roassal design points for scalability if it will use athens for real
On May 6, 2013, at 9:51 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Seriously nothing changed from 6 months in athens. The tutorial is just taking the class
side examples and put them in a kind of class.
Do you have a simple liste?
so to come
back to my key original question: when will roassal will start to use for real existing
infrastructure?
:-)
When we will have time and resources. Athens has been in a usable state only until
recently, when Igor made his tutorial. We are using Athens and we will continue to do so.
More and more Athens will become the base of Roassal. It is just that it takes time.
Ok push and mathieu can help.
When do you
plan to really have a look and optimise (1) speed and (2) garbage generated?
Over the last weeks, Roassal went through a major optimization process. Roassal has pretty much all the optimization that ZVMT
has (the library of Emmanuel, from INRIA).
can you elaborate?
More has to be done I agree.
By the way, if the Synectique crew (or anyone else) find some particular situations that
are judged as too slow, then we will make sure the slowdown get properly removed.
Thanks. We want Roassal to be really sexy.
Alex do you plan to visit us before ESUG?
It is still early for me to know. In a couple of weeks I will let you know
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
6:08 p.m.
New subject: About roassal design points for scalability if it will use athens for real
Seriously nothing changed from 6 months in athens. The
tutorial is just taking the class side examples and put them in a kind of class.
Each time I tried I run into problems. Now it works like a charm. Things have improved.
Over the last
weeks, Roassal went through a major optimization process.
Do you have a simple liste? Roassal has
pretty much all the optimization that ZVMT has (the library of Emmanuel, from INRIA).
can you elaborate? More has to be done I agree.
By the way, if the Synectique crew (or anyone else) find some particular situations that
are judged as too slow, then we will make sure the slowdown get properly removed.
Thanks. We want Roassal to be really sexy.
Alex do you plan to visit us before ESUG?
It is still early for me to know. In a couple of weeks I will let you know
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4245
days inactive
4250
days old
25 comments
6 participants
participants (6)
-
Alexandre Bergel -
Ben Coman -
Igor Stasenko -
stephane ducasse -
Stéphane Ducasse -
Usman Bhatti