Re: [Gzz] OrthoCoordsys???

[Benja Fallenstein]

Tuomas Lukka wrote:

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

I don't understand-- in the current interface, we compute the clip rect 
for *all* vobs, whereas if it were queried from the Coorder, it would 
only be computed for vobs that need it (connections clip differently).

Unless you mean creating the Rectangle object? That's not what I mean-- 
I want to continue using the current approach, where the data is written 
into an existing Rectangle.

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

Yes. What I mean is that the GL tests can only run when GL is compiled-- 
which needs the dependencies installed. Do you want to make that a 
requirement for compiling Gzz? For the group, that maybe isn't that much 
of a problem, but we want others to be able to compile it relatively easily.

> Have you already gotten OpenGL running on your laptop?

No, I'm waiting for Tuukka's docs.

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

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.

Of course, if you want to cache the subsys, things are different: you'd 
put them into a vobscene at the root level, and then we'd need a 
putAll() to put a whole vobscene into another one. But you don't want to 
cache most subsys (even if you cached all cells, you would have e.g. the 
padding coordsys inside the cells).

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

Why's that so different?

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

Yes, and we use them, but they get a scale number, not width and height. 
(We could of course store scales in the vobscenes, and multiply the 
child's scale with the parent's scale, as I suggested before.)

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

Argl!

Ok, what do we do about that?

- Benja