gzz-commits
[Top][All Lists]
Advanced

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

[Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst


From: Benja Fallenstein
Subject: [Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst
Date: Sun, 06 Oct 2002 12:27:42 -0400

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      02/10/06 12:27:42

Modified files:
        doc/pegboard/1009: PEG_1009.rst 

Log message:
        comment

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1009/PEG_1009.rst.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1009/PEG_1009.rst
diff -c gzz/doc/pegboard/1009/PEG_1009.rst:1.4 
gzz/doc/pegboard/1009/PEG_1009.rst:1.5
*** gzz/doc/pegboard/1009/PEG_1009.rst:1.4      Sun Oct  6 12:16:00 2002
--- gzz/doc/pegboard/1009/PEG_1009.rst  Sun Oct  6 12:27:42 2002
***************
*** 3,10 ****
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 16:16:00 $
! :Revision: $Revision: 1.4 $
  :Status:   Incomplete
  
  Transformations
--- 3,10 ----
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 16:27:42 $
! :Revision: $Revision: 1.5 $
  :Status:   Incomplete
  
  Transformations
***************
*** 26,31 ****
--- 26,39 ----
  
  .. IMPORTANT::
      Should 3D scaling be here as well?
+     
+ (Benja says:)
+  
+     ``scale`` doesn't belong here, because AWT cannot do it properly
+     when text is involved (because text's aspect ratio may change
+     with size).
+     
+     (Therefore, 3D scale doesn't belong here, either.)
  
  And into AffineVobCoorder the following functions::
  
***************
*** 40,45 ****
--- 48,58 ----
      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...
  
  Also, for all these functions, we should have a shorthand
  in VobScene:
***************
*** 47,73 ****
      public int translateCS(int into, Object key, float x, float y);
  
  just to make it a little easier to say them.
  For the affine ones, the VobCoorder is cast into AffineVobCoorder, and
  the error propagated if it's not.
  
! Transforming points interactively
! ---------------------------------
  
  It would be nice to be able to easily transform points to and from
  coordsystems, since we now have hierarchies. Since the coordsys are
  known incrementally, it should not be a problem to provide in VobCoorder::
  
      /** Transform one or more points to screen coordinates from the given cs.
       * @param into The array to store the results in.
       */
      public void transformPoints3(int withCS, float[] pt, float[]into) ;
  
      /** Transform one or more points from screen to given CS.
       * @return True, if a reasonable inverse was found.
       */
      public boolean inverseTransformPoints3(int withCS, float[] pt, 
float[]into) ;
  
  At the same time, remove VobCoorder.getRenderInfo as unnecessary.
  
  The reason for allowing the array ``pt[]`` to contain several points is
  simply performance.
--- 60,105 ----
      public int translateCS(int into, Object key, float x, float y);
  
  just to make it a little easier to say them.
+ 
+     (Benja:) How about just ``translate``?
+ 
  For the affine ones, the VobCoorder is cast into AffineVobCoorder, and
  the error propagated if it's not.
  
!     (Benja:) Not sure about error propagation: we need to make sure
!     that we can catch the error at a high level and look at it and
!     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.)
! 
! 
! Transforming points into coordinate systems
! -------------------------------------------
  
  It would be nice to be able to easily transform points to and from
  coordsystems, since we now have hierarchies. Since the coordsys are
  known incrementally, it should not be a problem to provide in VobCoorder::
  
      /** Transform one or more points to screen coordinates from the given cs.
+      *  Each point is represented as three values (x,y,z) in pt[].
       * @param into The array to store the results in.
       */
      public void transformPoints3(int withCS, float[] pt, float[]into) ;
  
      /** Transform one or more points from screen to given CS.
+      *  Each point is represented as three values (x,y,z) in pt[].
       * @return True, if a reasonable inverse was found.
       */
      public boolean inverseTransformPoints3(int withCS, float[] pt, 
float[]into) ;
  
  At the same time, remove VobCoorder.getRenderInfo as unnecessary.
+ 
+     (Benja:) I think ``inverseTransformPoints3`` should raise an exception
+     if no reasonable inverse can be found.
  
  The reason for allowing the array ``pt[]`` to contain several points is
  simply performance.




reply via email to

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