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

stephane ducasse

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

Because if there is only one coordinate system, then zooming in and out accumulate floating point errors.
I am pretty sure Cairo has a translation mechanism under the wood.

Athens has indeed fast primitives to do this. We will probably consider using them this once Athens will be part of Pharo.

I do not understand why you insist on saying that.

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
[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

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

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

abergel

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

In reply to this post by stephane ducasse

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

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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 8 May 2013 22:19, Alexandre Bergel <[hidden email]> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

--
Best regards,
Igor Stasenko.
_______________________________________________
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 9 May 2013 01:59, Igor Stasenko <[hidden email]> wrote:

> On 8 May 2013 22:19, Alexandre Bergel <[hidden email]> 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.

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