[Weston] More discussion about weston output relative motion algorithm

[Pekka Paalanen]

On Wed, 7 May 2014 08:49:47 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> > -----Original Message-----
> > From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> > Sent: Wednesday, May 7, 2014 3:41 PM
> > To: Wang, Quanxian
> > Subject: Re: [Weston] More discussion about weston output relative
> > motion algorithm
> > 
> > On Wed, 7 May 2014 07:03:32 +0000
> > "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
> > 
> > >
> > >
> > > > -----Original Message-----
> > > > From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> > > > Sent: Wednesday, May 7, 2014 2:17 PM
> > > > To: Wang, Quanxian
> > > > Michael Subject: Re: [Weston] More discussion about weston
> > > > output relative motion algorithm
> > > >
> > > > On Wed, 7 May 2014 03:26:56 +0000
> > > > "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
> > > >
> > > > > Thanks Pq's comment. Before you continue my comment, I
> > > > > mentioned one
> > > > point.
> > > > > This is output movement algorithm and it is completely
> > > > > different with pre-
> > > > configuration of output in weston.ini.
> > > > > For output, no alive, no movement.
> > > > > If you want to keep pre-configuration in weston.ini when
> > > > > output change,
> > > > just keep it in some place and follow it when pre-defined
> > > > output is plugged or unplugged. But anyway, it is a static
> > > > configuration.  It is conflict with dynamic output movement.
> > > > >
> > > >
> > > > Of course it is, but users expect both to work at the same
> > > > time, not have an option to choose between dynamic and static
> > > > configuration. They want to configure what the dynamic code
> > > > will do on hotplug, hence these two cases are inseparable.
> > > >
> > > > The weston-randr protocol could be seen as a way to modify the
> > > > static configuration in-memory and then trigger a re-layout.
> > > >
> > > > Btw. there is no reason to avoid negative global coordinates.
> > > > If you have output A at 0,0 and add output B to the left of it,
> > > > it is perfectly valid to put B at -widthB,0. You *can* add to
> > > > the left or above without moving all the existing outputs. Also
> > > > nothing says that you have to have an output with origin at
> > > > 0,0. (There may be bugs, but that is all.)
> > > [Wang, Quanxian] no negative coordinate happens. Top left most is
> > > the (0,0), it is the primary output.
> > 
> > You misunderstood. I mean that sometimes it is *good* to use
> > negative coordinates, exactly to avoid moving the world, and that
> > is *perfectly ok*.
> > 
> > Moving the world (all existing outputs) is usually not what a user
> > might expect when adding a new output.
> > 
> > The top-left most output does not need to be at 0,0.
> > 
> > > When you move output left of or
> > > above primary output(0,0), other outputs will be moved
> > > consistently based on the change. Once you primary output is
> > > changed, for example in this case, primary output will be changed
> > > to another output.  All others outputs' coordinate will be
> > > calculated again. But the relative position between outputs will
> > > not be changed. Top left most output is the root of tree. All
> > > other outputs must be descendants of it.(including clone link,
> > > hlink, vlink).  Output movement algorithm have implemented that.
> > > Negative coordinate is invalid.
> > 
> > I'm not talking about your specific algorithm anymore. I am talking
> > in general.
> > 
> > Existing outputs are usually expected to stay put, when adding
> > outputs to the extremes. Literally that means that the position of
> > the existing outputs must not change, but only the position of the
> > new output is computed appropriately, even if it results in
> > negative coordinates.
> > 
> > If I have one output active, and I add another output to the left
> > of it, I certainly do not expect all windows to jump from the
> > existing output to the new output. IOW, the position of the
> > existing output must not change, and the new output will get a
> > negative position.
> > 
> > This is about the absolute global coordinates, not the relative
> > positioning between outputs.
> [Wang, Quanxian] Hi, Pq
> After getting your opinion, I called back my initial thought for this
> algorithm.  I ever thought it like you, but after draw them one by
> one, I found I was wrong. The following information will tell you how
> to get the principle of algorithm.
> 
> How to get that principle?
> Take a very simple example, it is a horizontal link.
> Current output layout:
> A->B->C->D
> Next action:  Move new E output into left of C
> A->B->E->C->D
> 
> Question: Can you keep un-changed on all output's coordinate? 
> Absolutely not. C and D will be changed(right extension) or A and B
> are changed (left extension). Take common case to allow right
> extension. E will take place of C, C and D's coordinate will be
> changed at the same time. It is the minor change. The same thing for
> moving E leftof A. They are the same principle. Therefore in this
> case no negative happens. We implicitly support right extension.

That is obvious, and not the case I was talking about.

I meant this very simple example:

There is only one output A.

A

Then I add output B to the left of A.

B->A

The position of A must not change. This means that B must get negative
coordinates, and A's position stays at 0,0. In Weston, window positions
are stored in global coordinates, and to keep windows that were on
output A, still on output A, the position of A must not change.

Note, that you cannot infer this from the syntax "B->A", but you can
from "put B left-of A": B is being set and A is the reference point.


Another case:

First we have
A->B

Then "add C right-of A".

Now you could get the chain A->C->B, or C could end up cloning B. I
do not care too much on what happens there, since it is sort of
ill-defined. But I do care about the first case where we are not adding
in the middle.

> Now you get the principle from simple link. And then vlink is the
> same thing. And then combine vlink and hlink together. At last I got
> this algorithm. I know principle will exist in both complex and
> simple layout. The algorithm can be summarized from them. Therefore
> my first step is to study simple case and find what the rule is. And
> then turn to complex and enhance the algorithm. Make the algorithm to
> be complete.
> 
> Here I list several questions for you.
> 1) Why use tree to link all outputs together?
> If just use coordinate to calculated the x, y, you will be lost.
> Because when you moving output, you can't avoid affecting the
> position of other outputs. You have to review all coordinates of
> outputs and make decision who is left, right, above, below. It will
> be much more complex. But if you use tree to link all, everything is
> very clear. Who is left, right, above, below. It is very clear.
> Coordinate and relative motion could be easily figured out.
> 
> It will be very easy to control the position and movement of outputs.

My alternate proposition was to keep the ordered list of configuration
directives instead of a tree structure. Not just x,y for each live
output.

Instead of going through the tree to assing new positions, you would
execute the list of directives.

You would also need some additional rule on where to add outputs that
are not placed by any directive. Most likely this rule would just
create directives for the outputs.

Whether that would work or not, I am not sure.

> 2) Why one root
> One root will tell you, this is the top left most. No other outputs
> will be left or above it. From this, you can calculate and review all
> outputs. No one is lost.

Your definition of top-left most causes you to have problems in
realizing an arrangement where the top-left output does not exist, e.g.:

- C
B A

OTOH with directives, there is no need to define a root output.

Directives could also refer to inactive outputs. Inactive outputs would
simply have zero size, and the directive would be executed as always.

> 3) Why only one parent?
> If two parents, you will find more links will cross each other. It is
> absolutely a disaster. (This could cause conflict of coordinates,
> from this path, it will A, for that path, it will B. A and B is not
> same.)
> 
> I am not sure if you understand my idea. Sorry for my poor language.

No, I do understand the tree structure well. It is just the rationale
behind that is unclear, it clearly has some reasonable cases it
cannot represent, and some IMO surprising behaviour.


Thanks,
pq