44 |
layout, because *the aspect ratio changes*, as I have said above. |
layout, because *the aspect ratio changes*, as I have said above. |
45 |
You *cannot* assume that you can scale below the view level in AWT. |
You *cannot* assume that you can scale below the view level in AWT. |
46 |
|
|
47 |
|
(Tjl:) I didn't make my point clear. We *can* do this, |
48 |
|
if we ask, at vobscene construction time, |
49 |
|
how tall a given cs will be. |
50 |
|
|
51 |
And into AffineVobCoorder the following functions:: |
And into AffineVobCoorder the following functions:: |
52 |
|
|
53 |
int rotate(int into, float degrees); |
int rotate(int into, float degrees); |
|
int rotate3D(int into, float degrees, float x, float y, float z) ; |
|
54 |
int scale(int into, float x, float y, float z); |
int scale(int into, float x, float y, float z); |
55 |
|
|
56 |
.. IMPORTANT:: |
.. IMPORTANT:: |
57 |
Should we add default implementation of rotate? |
Should we add default implementation of rotate? |
58 |
|
|
|
.. IMPORTANT:: |
|
|
Should rotate3D really be there? It extends the capabilities? |
|
|
Should there be a third interface, ThreeDCoorder? |
|
|
Or leave it into GLVobCoorder for now, like distort? |
|
|
|
|
|
(Benja says:) What would rotate3D be for? In our 2 1/2 D world, the z axis |
|
|
is really different from x and y... |
|
|
|
|
|
(Tjl:) Well, have you looked at fillets demo? We don't always |
|
|
want to keep in a 2 1/2 D world. Sometimes 3D is nice. |
|
|
But maybe best to leave it to GLVobCoorder. |
|
|
|
|
|
(Benja:) Ok. |
|
|
|
|
59 |
Also, for all these functions, we should have a shorthand |
Also, for all these functions, we should have a shorthand |
60 |
in VobScene: |
in VobScene: |
61 |
|
|
63 |
|
|
64 |
just to make it a little easier to say them. |
just to make it a little easier to say them. |
65 |
|
|
|
(Benja:) How about just ``translate``? |
|
|
|
|
|
(Tjl:) Want to make sure it's not interpreted as "translate this vobscene". |
|
|
|
|
|
(Benja:) Hmmm... ok... ``translateCS`` just seems hard to write. |
|
|
|
|
66 |
For the affine ones, the VobCoorder is cast into AffineVobCoorder, and |
For the affine ones, the VobCoorder is cast into AffineVobCoorder, and |
67 |
the error propagated if it's not. |
the error propagated if it's not. A direct cast is not permitted; |
68 |
|
the functions must check ``instanceof`` and then throw |
69 |
(Benja:) Not sure about error propagation: we need to make sure |
NotAffineVobCoorderException, which is a subclass of |
70 |
that we can catch the error at a high level and look at it and |
UnsupportedOperationException. |
|
be *sure* that the reason for it is that one view needs an |
|
|
``AffineVobCoorder``, and we also need to know which view, so |
|
|
that we can give a reasonable error message to the user. (This |
|
|
is the direction into which we need to be moving... because this |
|
|
is not a programming error when it happens, it is that a view |
|
|
is used in an environment it wasn't programmed for, which may |
|
|
happen in a production system.) |
|
|
|
|
|
(Tjl:) How about UnsupportedOperationException? Hmm.. |
|
|
or a subclass of that, NotAffineCoorder |
|
|
|
|
|
(Benja:) Subclass, because a) we need to store the view in |
|
|
the exception, and b) ``UnsupportedOperationException`` is |
|
|
raised by *many* things, not safe to use at all. |
|
|
|
|
71 |
|
|
72 |
Transforming points into coordinate systems |
Transforming points into coordinate systems |
73 |
------------------------------------------- |
------------------------------------------- |
84 |
|
|
85 |
/** Transform one or more points from screen to given CS. |
/** Transform one or more points from screen to given CS. |
86 |
* Each point is represented as three values (x,y,z) in pt[]. |
* Each point is represented as three values (x,y,z) in pt[]. |
87 |
* @return True, if a reasonable inverse was found. |
* @return True, if a reasonably accurate inverse was found. |
88 |
|
* If an inverse cannot be found, a reasonable attempt shall |
89 |
|
* be made to give a point close (e.g. if an affine transform |
90 |
|
* is singular / near-singular, pick a point on the line |
91 |
|
* that's close to the original. |
92 |
*/ |
*/ |
93 |
public boolean inverseTransformPoints3(int withCS, float[] pt, float[]into) ; |
public boolean inverseTransformPoints3(int withCS, float[] pt, float[]into) ; |
94 |
|
|
95 |
At the same time, remove VobCoorder.getRenderInfo as unnecessary. |
At the same time, remove VobCoorder.getRenderInfo as unnecessary. |
96 |
|
|
|
(Benja:) I think ``inverseTransformPoints3`` should raise an exception |
|
|
if no reasonable inverse can be found. |
|
|
|
|
|
(Tjl:) One that requires catch() or one that doesn't? |
|
|
I don't really like the exception either way: a pseudoinverse |
|
|
(closest to real inverse) can be well-defined. |
|
|
|
|
|
(Benja:) Hm. So is the method supposed to return ``true`` |
|
|
if the inverse that was found is real? Then need to change |
|
|
javadoc: a pseudoinverse is "reasonable" IMHO. On the other |
|
|
hand, if there are cases where no usable inverse can be found, |
|
|
we need the exception (not sure which type). |
|
|
|
|
97 |
The reason for allowing the array ``pt[]`` to contain several points is |
The reason for allowing the array ``pt[]`` to contain several points is |
98 |
simply performance. |
simply performance. |
99 |
|
|