/[gzz]/gzz/doc/pegboard/1009/PEG_1009.rst
ViewVC logotype

Diff of /gzz/doc/pegboard/1009/PEG_1009.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.8 by benja, Sun Oct 6 16:52:16 2002 UTC revision 1.9 by tjl, Sun Oct 6 17:24:00 2002 UTC
# Line 44  Add into VobCoorder the following conven Line 44  Add into VobCoorder the following conven
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    
# Line 74  in VobScene: Line 63  in VobScene:
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  -------------------------------------------  -------------------------------------------
# Line 116  known incrementally, it should not be a Line 84  known incrementally, it should not be a
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    

Legend:
Removed from v.1.8  
changed lines
  Added in v.1.9

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26