Re: [Gzz] OrthoCoordsys???

[Benja Fallenstein]

Tuomas Lukka wrote:

> > > No, but it's less interface changes. Changing interfaces when it's
> > > not really necessary is bad.
> > >      
> > The point is that a) the current interface is terribly twisted, 
> >    
>
> How?

'cuz the OrthoCoorder has to create the RenderInfo first, and 'cuz you 
have to create new RenderInfo objects when querying different coordsys' 
coordinates, and 'cuz RenderInfo is an inner class of Vob for no good 
reason except history. I simply think all of these are annoying. But the 
most important reason for me probably is that the code to put the 
information into RenderInfo is always so difficult to change.

> > > Umm, who says *YOU* should take care of that?
> > > I'd think it would go so that you call VobScene.getSubVobscene()
> > > which returns a new vobscene. If you care about efficiency, you release()
> > > the subvobscene in the end so it can be used again, but that's not vital.
> > >
> > >      
> > Ok.
> >
> > I don't like it. When I create a coordsys, I get an int, not a vobscene. 
> > When I place a vob, I use that int. When I call another function that 
> > places a vob, I pass the int. When I call another function that places 
> > coordinate systems, I'd need to call getSubVobscene(coordsys) and pass 
> > that. Can I place vobs in that sub-vobscene? No, not without an 
> > interface change, only coord systems, and then vobs in those coord 
> > systems. It seems terribly inconsistent.
> >    
>
> Huh??? Why can't you place vobs in the sub-vobscene? THe point
> was that the users of that subvobscene would see it exactly as
> a vobscene, NO interface changes required.

Ok, I didn't explain this clearly enough.

ContentViews are currently called with a vobscene and a coordsys int. 
Then they have a choice: Place one or more vobs into that coordsys 
(e.g., just a single textvob); or, place subsys into the coordsys and 
put vobs into that.

We need to retain both options, the first for ContentViews that can show 
their content as a single vob (e.g., an image span vob maybe); and the 
second because many content views want to do more sophisticated things, 
e.g. span text broken into lines.

If ContentViews were passed only a vobscene, they would thus have to 
have a way to "put a vob into the vobscene:" not into *a coordsys inside 
the vobscene*, but *the whole vobscene*. That is what I meant above.

If we take this approach, we'd then have two things here: put a vob into 
a coordsys inside a vobscene, and put a vob into a vobscene as a whole. 
This is not nice, and is an interface change also. -- Another 
possibility would be to have only this: you never give a coordsys 
number, but always use a vobscene object and put the vob into that. This 
would be more consistent.

However, I like the int approach best because it gives maximum 
flexibility: E.g., I can get the parent of the coordsys I'm supposed to 
put things into, then search for other coordsys in the parent coordsys 
which have a specific key, then query the position of that other 
coordsys, then layout something in my coordsys according to that 
information. I simply like this kind of flexibility.-- As a practical 
example, I might want to get the clipping area of my coordsys' parent 
when drawing some vob that has special clipping needs (such as text 
vobs, which might sometimes want to go outside padding boundaries). I 
like to be able to query that information through a consistent interface.

Of course, as I said in my other email, it's your choice in the end. I'm 
just expressing my preference here.

> > The old API simply didn't allow you to do the things the new API allows 
> > you to do, so it seemed reasonable that CellContentViews are passed ints 
> > while Views are only passed VobScenes. Now this is an inconsistency. We 
> > change the API in any case (adding getSubVobscene in your proposal), and 
> > one way makes it inconsistent, and another way makes it consistent. I 
> > like the latter better.
> >    
>
> Well, my opinion of what is consistent is the opposite: both views and
> cellcontentviews are passed vobscenes and they do the same things
> with them.

(Same comments as above... ;) )

> > > > Ok, so we'd need sorting in GL anyway, even if we place all the coordsys 
> > > > in one vobscene at a time? If so, why don't we make it a recommendation 
> > > > instead of a requirement to put all the coordsys at the same time?
> > > >        
> > > Sorting?
> > >      
> > If it's not sorting, what makes it slow?
> >    
>
> Ahh.. the fact that you're entering and exiting all the parent coordinate
> systems at the same time.
>
> That is, if you want things to really interpolate right, you have to 
> not just store the innermost coordinate systems but the whole chain
> and interpolate that. This gets especially important with rotations.

Hm, I don't understand en detail right now, but I'm just going to 
believe you :-)

> > > > > So that OpenGL
> > > > > gets the scaling right. I think that in some ways the current system is 
> > > > > too simplistic:
> > > > > if I put a vob at (50,50) that is (100,100) in size, then how should the 
> > > > > coordinate
> > > > > system inside it behave? My initial reaction is that it should be 
> > > > > selectable,
> > > > > so that you can say "Oh, and inside, the point (50,50) is (0,0) and 
> > > > > (100,100) is (10,26)".
> When you put in a "viewport" to another coordinate system, in your case the 
> cell content
> view's coordinate system, there are two distinct things:
>
> 1) what edges is the content that was put inside clipped against?
> and
> 2) what is the coordinate system inside.
>
> You can separately specify that
>         1) clip it into the rectangle (50,50)--(150,150)
> and
>         2) inside, the coordinate system is such that the origin is at (83,90)
>            and the unit vectors are (1,1) and (0,2) (a skewed coordinate 
> system).

Ok, thanks for the explanation. Now I understand.--

My initial reaction was to do that with two different coordsys inside 
each other: a coordsys at (x=50, y=50, w=100, h=100), and one at (x=33, 
y=40) inside the other one to do the translation inside the viewport. 
This is how the AWT client does the text scrolling inside a cell: it 
places the text into a coordinate system that is moved inside the 
clipping coordinate system.

However, then I understood that this wouldn't work because of the 
scaling/skewing: In an orthogonal system, do or don't the things inside 
a coordsys scale with its width and height? In the clipping coordsys, 
they shouldn't; in the other coordsys, they should. Also, when using 
affine transformations, if I understand correctly, you want to say, "use 
these unit vectors," and not, "use the parallelogram (is that an English 
word?) spanned by these two vectors as the boundary of this coordinate 
system."

> > > That's why I'm opposed
> > > to your int system. 
> > >      
> > "int system"?
> >    
>
> Of using the index of a *single* coordinate system as a parent.
>
> As I explain above, there are two different issues here, which the int system
> 1) partially makes impossible to do generally, by assuming that the unit 
> vectors are
>   always (1,0) and (0,1)

(Nit: It only assumes that the absolute values of the unit vectors are 1 
with affine transformations. But I understand your point.)

> and
> 2) partially mixes with each other, by insisting that the origin be at the same
>   point as the clipping rectangle's origin.

That is purely philosophical. :-) I would have argued that your proposal 
mixes two different issues with each other here: the clipping and the 
translation against the clipping. I would have used two independent 
coordinate systems to do that, as I believe PUI viewports do. But as I 
said, it's purely philosophical: you can make arguments in favor of both 
POVs, but that won't get you anywhere.

(A practical point in favor of not mixing the two is that they usually 
change independently from each other: If you click on a different place 
of the paper inside the viewport, its position relative to the clipped 
rect changes, but the clipped rect remains the same; if you click on a 
different paper, the first paper's clipping rect goes to a different 
position, but the paper's position relative to the clip rect doesn't 
change.)



Ok, anyway. I'm not actually opposed at all to using the system you 
proposed in GL (more generally, in a system supporting affine 
transformations). I do see practical problems with AWT, so let's think 
about how to solve them.

Actually, it boils down to that AWT cannot scale in two dimensions 
arbitrarily if text drawing is involved (if you scale the width without 
scaling the height, you don't get the results you may have expected). 
So, I believe we shouldn't ask the system to support this, because it 
cannot do so reasonably.

What we *can* conceivably do is using a single scale for both x and y-- 
then we could also scale the font sizes by the same scale. But font 
sizes don't scale uniformly, so we'd get bad results actually. So I 
think we simply don't want to support scaling in AWT, and thus 
OrthoCoorder. (This means that we always assume unit vectors (1,0) and 
(0,1) when converting this to affine coords... or alternatively, if we 
have a single scale s, we'd assume unit vectors (s,0) and (0,s).)

We could solve the translation problem by adding two additional 
coordinates to creating a coordsys in OrthoCoorder, maybe called tx and 
ty (translation coordinates). In AffineCoorder, we'd also add 
coordinates for the unit vectors...

I still don't like it a terrible lot, because it's not clear what vobs 
are put into: the rectangle also used for clipping? If we can do it with 
two coordsys placed into each other somehow, I'd prefer that approach. 
But above all, I'd urge you to simply make a decision here.

> Ok, to avoid a worse flamewar, let me vent my feelings a little:
>
>         Yes, I AM annoyed that I discover days before a release that
>         an API has been changed incompatibly without regard for the OpenGL
>         implementation. I'd have much preferred if it had been a branch, or
>         first a proposal to the mailing list.

Ok, there is a different, completely non-technical problem here that we 
may need to talk about. I think I need to rant a little here, too.

I *have* proposed this on the mailing list (in my July 5th report), as 
mentioned in my first commit msg for this. I didn't get any replies to 
this proposal, and therefore assumed that nobody's opposed to it. Now it 
seems more like nobody seriously thought about it.

It has happened a few times before that I've sent something to the list 
and didn't get any reply. This spring, this was the case with URI cell 
ids (including the idea for an informal URN namespace IIRC). For a long 
time I took the lack of any reaction to mean, nobody thinks this is 
worth the time. Then at some point I decided it may also mean a lack of 
opposition, and made a posting saying, "I'm gonna do this if nobody 
speaks up against it." Nobody did, so I started the registration (and 
now you even want to write an article about it).

But now I find that in another case (this), the lack of reply indicates 
that this has not been discussed enough beforehand to be actually 
implemented.

I do not see how I can work if a) I don't get replies to my proposals 
and b) the meaning of those non-replies changes seemingly randomly. :(

Ok, now I feel a little better, too. ;)

- Benja