Re: [Gzz] OrthoCoordsys???

[Tuomas Lukka]

> I'm very much coming to think that the Vob.RenderInfo interface is 
> wrong. Instead, you should be able to query this information from 
> VobCoorder, giving the coordsys number. Then e.g. getting the clip rect 
> would be much easier-- the method could recursively call itself. Do you 
> think such an interface change would be ok?

Not sure: the problem is, once again, performance. Querying it means
that the coorder must create it. Could you make a branch and benchmark
it?

> >And that the meanings of some quite central APIs had changed without
> >adjusting jython code...
> >
> 
> Yes, this is something we need to think about: All Jython code must be 
> tested if you want it to remain usable after this kind of interface 
> change. With Jython code depending on GL this is of course not easily 
> possible... what to do about that?

We need tests for all jython code anyway since we'll have more and
more of it, and tests for OpenGL also anyway. Creating suitable
unit tests for OpenGL is not that difficult.

Have you already gotten OpenGL running on your laptop?

> BTW, I think that all code should be updated to use the parent coordsys 
> interface: it's as easy as handing down one additional number through 
> the hierarchy, and it greatly increases flexibility.

Hmm... but might it not be more efficient to have a facade VobScene
so that you just put it normally into the vobscene?

> >>There are four issues involved here.
> >>
> >>1. Coordinates
> >>
> >>OrthoCoorder stores the coordinates (and depth) absolute, not relative 
> >>to the parent coordsys, even though it gets the coordinates relative to 
> >>the parent. It simply adds the parent's x, y, and depth coordinates to 
> >>its own.
> >>   
> >>
> >
> >Yes. In OpenGL, we have a completely different set of tradeoffs 
> >that would have been nice to think about in the design: in OpenGL,
> >it's cheap to do real hierarchical cs, if you do all child cs
> >inside a parent cs at one time.
> >
> 
> Hm, interesting. That's really so even if you don't do the vobs at the 
> same time-- i.e., if you do all child cs at one time, but add additional 
> vobs into them at a later time? (If not, it's not very useful, as we 
> need to be able to add connections later.)

If you don't sort after that, it's going to be slower. But sorting
has its own problems; changing the OpenGL plotting modes
also makes things slower.

But of course connections are different: they use two coordinate systems...


> >BTW: the coordinate stuff is also not quite all thought out yet, as
> >you don't scale the coordinates by the parent's coordinates; 
> >the way a coordinate system is "put into another" is quite arbitrary:
> >it translates but does not scale. In OpenGL, we'd of course want it
> >to scale as well as rotate, skew.
> >
> 
> Yes. That is because in AWT, scaling is not so simple, because of the 
> way fonts work. Ideas about this?

We do have scalable fonts implemented already in our code. 

> >>3. Clipping
> >>
> >>In OrthoCoorder, the clip rect is found by going through all parents of 
> >>a coordsys and taking the maximum left and upper and the minimum right 
> >>and lower coordinates of all ExtRects. (OrthoCoorder doesn't do this 
> >>right during interpolation, yet.)
> >>   
> >>
> >
> >Clipping is even harder to get right in OpenGL...
> >
> 
> Uh. Why?

Because you're not always orthogonal. If you clip into a square, rotate,
clip into another square you suddenly have an octagon. And you can't
usually have 8 clip planes in OpenGL.

> Because I want to think w[cs], not coords[cs*7+3]. In OrthoCoorder, the 
> performance gain from using a single array is very likely negligible, 
> but the readability gain by using different arrays is quite large.

Ok.

        Tuomas