Re: [Gzz] OrthoCoordsys???

[Tuomas Lukka]

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

> and b) 
> we really should be able to get information about coordsys other than 
> our own when drawing: for example, a connection may want to clip by the 
> smallest common ancestor of its two coordinate systems, and as another 
> example, we frequently need to query information about different 
> coordsys during view building. Currently we can do this, and we do this, 
> by using Coorder.getRenderInfo(cs), which is neither efficient (creates 
> objects) nor clean.

Ok, this is a reasonable justification for changing the API.

> Besides, what you said earlier is that you were worried about 
> performance, and wanted benchmarks, not that changing interfaces is bad.

All those are important considerations.

If you want to change an API that other code uses, it has to
1) have good justification
2) not make performance worse


> >>>>>Hmm... but might it not be more efficient to have a facade VobScene
> >>>>>so that you just put it normally into the vobscene?
> >>>>>
> >>>>More efficient to have an additional Java object? I want coordsys to be 
> >>>>cheap, so that you don't have to worry about creating one more.
> >>>>
> >>>Yes, but the facade vobscene doesn't need to really *be* a vobscene:
> >>>it can work just like your implementation: contain an int inside. The 
> >>>point
> >>>is that then you don't have to keep passing the int around everywhere.
> >>>
> >>Intuitively, I don't like the gotchas here: forgetting to set the int 
> >>inside back when a function you've called returns.
> >>   
> >>
> >
> >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.

> >Then there's nothing that the user has to really care about.
> >
> >*AND* the API remains the same as before, which would be nicer.
> >
> 
> 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.

> >>>Because there it doesn't help that you are already in one because you 
> >>>have
> >>>to know coordinates in both of them anyway.
> >>>
> >>>     
> >>>
> >>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.

> >>>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)".
> >>>
> >>>How would you accommodate that?
> >>>
> >>>     
> >>>
> >>I think it *is* useful here to build on the thinking that has been done 
> >>already, so the mental model I started with was like putting PUI 
> >>components inside each other (which only translates). As for the next 
> >>step, what about finding out how Berlin does this? They *do* have the 
> >>same problem, after all.
> >>   
> >>
> >
> >Well, I've actually solved this problem once before for PP: there you have 
> >the
> >viewports to the larger papers. This is just about the same situation.
> >
> >The solution was simply to have two coordinate systems for each viewport:
> >1) the coordinate system for the edges
> >2) the coordinate system that the vobs inside obey.
> >
> 
> Please explain-- I don't understand at all. What are "edges"? This 
> doesn't seem to have anything to do with the discussion above.

It does, quite a lot. 

Ok. 

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

> >The point is that it's unreasonable to bind both the clipping *and* the 
> >internal
> >coordinate system to the same coordinate system. 
> >
> 
> ???

Does the above help?

> >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)
and
2) partially mixes with each other, by insisting that the origin be at the same
   point as the clipping rectangle's origin.

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.

        But: I'm not blaming you for the breakage of the OpenGL stuff - 
        quite simply the lack of unit tests makes it impossible to know
        that it's broken.

        Also, I think that the hierarchical stuff *IS* important to address,
        which also makes me anxious about the failings of the proposed system,
        especially when introduced at such a date.

        I *do* think that the lightweight idea could be made to work, but
        that it has to address the issues above, and also I *do* like
        the simplicity of no extra objects - but I'm still divided between
        whether it should be the subvobscene stuff or normal vobscene stuff.



        Tuomas