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...
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
On 6 May 2013 13:26, Alexandre Bergel alexandre.bergel@me.com wrote:
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.
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.
- 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.
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.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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.
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
On 6 May 2013 15:21, Alexandre Bergel alexandre.bergel@me.com wrote:
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.
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
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.
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?
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
On May 6, 2013, at 3:21 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
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.
did you try the code snippet of igor that I sent to the list? Because you can zoom in a vector graphics polymetric view.
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.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
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
On 8 May 2013 22:19, Alexandre Bergel alexandre.bergel@me.com wrote:
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.
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.
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 9 May 2013 01:59, Igor Stasenko siguctua@gmail.com wrote:
On 8 May 2013 22:19, Alexandre Bergel alexandre.bergel@me.com wrote:
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.
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.
- 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.
? 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.
- 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.
Use Athens because igor is much better than us on vector graphics and Athens has all that.
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.
this has nothing to do with traits. why you do not have ROArrrow reversed could probably works.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 6 May 2013 18:28, stephane ducasse stephane.ducasse@free.fr wrote:
- 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.
? 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.
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.
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.
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?
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
Maintaining virtual coordinates is essential for zooming and scrolling the whole view.
? I do not get why.
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.
Because we live by having Roassal and all our tools cross-platform. Focusing only on Pharo means that we cannot pay engineering work anymore.
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.
this has nothing to do with traits. why you do not have ROArrrow reversed
could probably works.
This is what the hierarchy looks like:
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.
Alexandre
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.
Because we live by having Roassal and all our tools cross-platform. Focusing only on Pharo means that we cannot pay engineering work anymore.
I can understand but if people use D3 instead of Roassal because roassal is too slow then you will miss your objective. Having a platform with the faster rendering is key. Because then your clients will ask about having the same on VW and VW use cairo too.
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,
I cannot let you say that. May be did not realise that athens was fully working since months. The tutorial is just a little tool to show examples. But the examples were there.
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.
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
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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
Hello,
On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 7, 2013, at 9:59 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
Hello,
On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
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.
the problem with huge graph is that you get lost. We should just use them to bench roassal.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, May 7, 2013 at 10:43 AM, stephane ducasse stephane.ducasse@free.frwrote:
On May 7, 2013, at 9:59 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
Hello,
On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
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.
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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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.
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@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@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.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 6, 2013, at 9:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
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.
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.
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.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 a rendering queue that contains nodes to be displayed on the screen. This list is adjusted when you scroll. Some caches have been added as well.
Roassal has pretty much all the optimization that ZVMT has (the library of Emmanuel, from INRIA).
can you elaborate?
I did not mean the optimizations, but more the cool concept of zvmt: the rendering queue, combining animation, sequence of animations, having a queue of animations instead of using threads.
Alexandre
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Ben Coman -
Igor Stasenko -
stephane ducasse -
Stéphane Ducasse -
Usman Bhatti