Re: [Gzz] OrthoCoordsys???

[Benja Fallenstein]

Tuomas Lukka wrote:

> The problem was of course also that OrthoCoordsys had no documantation
> whatsoever, as well as "cx", "cx2" like names.

Yes. The c* stuff is for clipping-- I needed some way to do that fast, 
because I was doing something entirely different (always showing the 
portion of a cell's text the cursor is at) and the inability to clip 
correctly hit me.

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?

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

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.

> > There are four issues involved here.
> >
> > 1. Coordinates
> >
> > OrthoCoorder stores the coordinates (and depth) absolute, not relative 
> > to the parent coordsys, even though it gets the coordinates relative to 
> > the parent. It simply adds the parent's x, y, and depth coordinates to 
> > its own.
> >    
>
> Yes. In OpenGL, we have a completely different set of tradeoffs 
> that would have been nice to think about in the design: in OpenGL,
> it's cheap to do real hierarchical cs, if you do all child cs
> inside a parent cs at one time.

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

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

> > 2. Interpolation
> >
> > The current semantics are: Interpolate only inside the parent coordset, 
> > i.e., interpolate A to B only if they have the same key *and* their 
> > parents are interpolated to each other.
> >    
>
> Yes, this is the one that causes the major breakage.

Ok, I understand. This shouldn't be a big problem.

> > This means that you need to do lookups by key *and parent*, and that 
> > means java.util.Maps won't suffice. I've implemented my own in 
> > OrthoCoordsysMap, which is tightly coupled to OrthoCoordsys.
> >    
>
> Maybe loosening that coupling would be the right way to go?

I think it would be easier if you take it and change it to fit the GL 
needs: a) It is extremely simple as is, at only 79 lines including the 
copyright boilerplate (but without the missing javadoc ;-)), so it 
should be easy to customize; and b) it needs a nextHashtableEntry[] 
array in OrthoCoordsys, because it takes the linked list approach to 
hashtabling. I don't know what approach you want to take for the GL 
stuff, but maybe you want to consider a linear hashtable.

> > 3. Clipping
> >
> > In OrthoCoorder, the clip rect is found by going through all parents of 
> > a coordsys and taking the maximum left and upper and the minimum right 
> > and lower coordinates of all ExtRects. (OrthoCoorder doesn't do this 
> > right during interpolation, yet.)
> >    
>
> Clipping is even harder to get right in OpenGL...

Uh. Why?

> > 4. Depth sorting
> >
> > In depth sorting, we draw first a coord system, then (above that) all 
> > coord systems in it, the (above that) the next coord system on the same 
> > level. The algorithm to do that takes some figuring out; see 
> > OrthoDepthSorter.cmp().
> >    
>
> And in OpenGL, depth sorting is not used at all - everything is drawn
> in the order it was put into the vobscene, enabling stupid OpenGL tricks.

Argl, yes. I can see why put-all-children-at-the-same-time would be 
good... Still not sure it'll work out, but not sure it won't, either.

> > Hm. Actually... I guess you could use OrthoCoordsys, in fact; you'd 
> > simply need to store the coordinates you need in it (neither 
> > OrthoCoordsysMap nor OrthoDepthSorter depend on the coords, I think).
> >    
>
> That would make things quite a bit slower: we need the coords in one
> contiguous array with 7 entries for each coordinate system.

Ok. You shouldn't use OrthoCoordsys for the GL stuff, then.

> > You could make OrthoCoordsys an abstract superclass (AbstractCoordsys), 
> > and remove the w and h arrays from it. Then you could make two 
> > subclasses, OrthoCoordsys (adding the w and h arrays), and 
> > AffineCoordsys (adding xx, xy, yx and yy arrays). Would that work for you?
> >    
>
> Why different arrays rather than one long one?

Because I want to think w[cs], not coords[cs*7+3]. In OrthoCoorder, the 
performance gain from using a single array is very likely negligible, 
but the readability gain by using different arrays is quite large.

- Benja