Re: [Gzz] OrthoCoordsys???

[Tuomas Lukka]

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

No, but it's less interface changes. Changing interfaces when it's
not really necessary is bad.

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

Then there's nothing that the user has to really care about.

*AND* the API remains the same as before, which would be nicer.

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

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

The point is that it's unreasonable to bind both the clipping *and* the internal
coordinate system to the same coordinate system. That's why I'm opposed
to your int system. 

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

Well, of course there's stenciling... *IF* available on the particular card
in a HW accelerated fashion.

        Tuomas