Re: [Gzz] OrthoCoordsys???

[Benja Fallenstein]

Tuomas Lukka wrote:

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

Ok. But again, I don't see why querying it from the coorder would be 
less efficient.

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

Oh, yes, definitely. BTW, fixing the error messages from the bot needs 
to go into TODO...

Probably the GL tests should be run after compiling GL.

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

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

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?

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

Yes, and the question what that means for text.

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

Yes. To do that, we need to think about what we want to use it for?

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

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

Ok. Hmmm... We *do* need clipping...

- Benja