Smalltalk › Frameworks & Tools › Moose

About roassal design points for scalability if it will use athens for real

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Stéphane Ducasse

About roassal design points for scalability if it will use athens for real

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...
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Igor Stasenko

Re: About roassal design points for scalability if it will use athens for real

On 6 May 2013 13:26, Alexandre Bergel <[hidden email]> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>

--
Best regards,
Igor Stasenko.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: 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.
>>
> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Igor Stasenko

Re: About roassal design points for scalability if it will use athens for real

On 6 May 2013 15:21, Alexandre Bergel <[hidden email]> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

--
Best regards,
Igor Stasenko.
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ben Coman

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by abergel

Alexandre Bergel 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.

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

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.

cheers -ben

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

stephane ducasse

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by abergel

>
>> * 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.

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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

stephane ducasse

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by abergel

On May 6, 2013, at 3:21 PM, Alexandre Bergel <[hidden email]> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

stephane ducasse

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by Stéphane Ducasse

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Igor Stasenko

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by stephane ducasse

On 6 May 2013 18:28, stephane ducasse <[hidden email]> 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?

--
Best regards,
Igor Stasenko.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Screen Shot 2013-05-06 at 7.39.22 PM.png (191K) Download Attachment

abergel

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by stephane ducasse

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

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by Igor Stasenko

> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by Ben Coman

> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by stephane ducasse

> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Usman Bhatti

Re: 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 <[hidden email]> 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.

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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

stephane ducasse

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by abergel

On May 6, 2013, at 9:51 PM, Alexandre Bergel <[hidden email]> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

stephane ducasse

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by Usman Bhatti

On May 7, 2013, at 9:59 AM, Usman Bhatti <[hidden email]> wrote:

Hello,

On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel <[hidden email]> 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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Usman Bhatti

Re: About roassal design points for scalability if it will use athens for real

On Tue, May 7, 2013 at 10:43 AM, stephane ducasse <[hidden email]> wrote:

On May 7, 2013, at 9:59 AM, Usman Bhatti <[hidden email]> wrote:

Hello,

On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel <[hidden email]> 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.

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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ben Coman

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by stephane ducasse

stephane ducasse wrote:

On May 7, 2013, at 9:59 AM, Usman Bhatti [hidden email] wrote:

Hello,

On Mon, May 6, 2013 at 9:51 PM, Alexandre Bergel [hidden email] 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.

Well, speaking hypothetically, it could be that only after getting lost in a huge graph do you realize you should produce a simpler graph, rather than blaming the platform and moving on.

cheers -ben
* Imagine if you will, a world without hypothetical situations.... *

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: About roassal design points for scalability if it will use athens for real

In reply to this post by stephane ducasse

> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev