Re: [Gzz] OrthoCoordsys???

[Tuomas Lukka]

On Fri, Aug 23, 2002 at 12:29:19PM +0200, Benja Fallenstein wrote:
> 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).

The *interface* doesn't say you have to do that... You can make a RenderInfo
implementation that does exactly what you propose.

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

I want at least to have the compilebot do it.

> >Have you already gotten OpenGL running on your laptop?
> 
> No, I'm waiting for Tuukka's docs.

Get on IRC sometime, we'll walk through it.

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

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.

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

Because there it doesn't help that you are already in one because you have
to know coordinates in both of them anyway.

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

And of course there is also separate horizontal and vertical scale.

Now, the first thing we need is to really specify 

        WHAT DOES IT MEAN TO PUT A COORD SYSTEM INSIDE ANOTHER

in a global sense where also affine coord systems work right. 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?

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

That I don't know. That's why I said it's even harder ;)

        Tuomas