Re: [Gzz] OrthoCoordsys???

[Benja Fallenstein]

Tuomas Lukka wrote:

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

The point is that a) the current interface is terribly twisted, and b) 
we really should be able to get information about coordsys other than 
our own when drawing: for example, a connection may want to clip by the 
smallest common ancestor of its two coordinate systems, and as another 
example, we frequently need to query information about different 
coordsys during view building. Currently we can do this, and we do this, 
by using Coorder.getRenderInfo(cs), which is neither efficient (creates 
objects) nor clean.

Besides, what you said earlier is that you were worried about 
performance, and wanted benchmarks, not that changing interfaces 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.

Ok.

I don't like it. When I create a coordsys, I get an int, not a vobscene. 
When I place a vob, I use that int. When I call another function that 
places a vob, I pass the int. When I call another function that places 
coordinate systems, I'd need to call getSubVobscene(coordsys) and pass 
that. Can I place vobs in that sub-vobscene? No, not without an 
interface change, only coord systems, and then vobs in those coord 
systems. It seems terribly inconsistent.

> Then there's nothing that the user has to really care about.
>
> *AND* the API remains the same as before, which would be nicer.

The old API simply didn't allow you to do the things the new API allows 
you to do, so it seemed reasonable that CellContentViews are passed ints 
while Views are only passed VobScenes. Now this is an inconsistency. We 
change the API in any case (adding getSubVobscene in your proposal), and 
one way makes it inconsistent, and another way makes it consistent. I 
like the latter better.

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

If it's not sorting, what makes it slow?

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

Please explain-- I don't understand at all. What are "edges"? This 
doesn't seem to have anything to do with the discussion above.

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

"int system"?

- Benja