gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] OrthoCoordsys???


From: Benja Fallenstein
Subject: Re: [Gzz] OrthoCoordsys???
Date: Thu, 22 Aug 2002 14:17:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3

Tuomas Lukka wrote:

No, that's not the problem. The problem is the *HIERARCHICAL*
coordinate systems, which changed a lot of APIs (and also made a lot of jython GL-using code not work any more).


Ah, I see. This doesn't have anything to do with OrthoCoordsys-- I implemented the hierarchical coord systems before I implemented the latter. OrthoCoordsys is just to make it faster (so that we don't need to be so worried about creating many coord systems).

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.

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.

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.

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

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

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

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?

-b.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]