[Gzz-commits] gzz ./TODO doc/pegboard/1003/PEG_1003.html doc/...

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Tuomas J. Lukka <address@hidden>        02/09/06 07:56:36

Modified files:
        .              : TODO 
        doc/pegboard/1003: PEG_1003.html coorders.java 

Log message:
        Update PEG 1003. We need to decide on this soon; it's necessary for the 
demos

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/TODO.diff?tr1=1.84&tr2=1.85&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1003/PEG_1003.html.diff?tr1=1.12&tr2=1.13&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1003/coorders.java.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gzz/TODO
diff -c gzz/TODO:1.84 gzz/TODO:1.85
*** gzz/TODO:1.84       Fri Sep  6 07:23:36 2002
--- gzz/TODO    Fri Sep  6 07:56:36 2002
***************
*** 58,64 ****
        - mediaserver - what demo?
        - a really comprehensive web page of screenshots
          and instructions on how to get them and run.
!       - unit tests for the designated demos.
      tjl:
        - Buoy placement
            - when quantity rises
--- 58,65 ----
        - mediaserver - what demo?
        - a really comprehensive web page of screenshots
          and instructions on how to get them and run.
!       - unit tests for the designated demos. We REALLY need to
!         avoid breakage on them from now on.
      tjl:
        - Buoy placement
            - when quantity rises
Index: gzz/doc/pegboard/1003/PEG_1003.html
diff -c gzz/doc/pegboard/1003/PEG_1003.html:1.12 
gzz/doc/pegboard/1003/PEG_1003.html:1.13
*** gzz/doc/pegboard/1003/PEG_1003.html:1.12    Mon Sep  2 12:58:42 2002
--- gzz/doc/pegboard/1003/PEG_1003.html Fri Sep  6 07:56:36 2002
***************
*** 9,173 ****
  <p>Hierarchical <tt>VobScene</tt>s need some fixing.<br>
   </p>
  
! <p>Open issues:<br>
!   </p>
  
! <ul>
!     <li>Is the integer identifier of the coordinate system into which to
! place  a new coordinate system appropriate?</li>
!     <li>Should plain coordinate systems be usable as those ints?
!        <small>(Benja:) "Plain coordinate systems"?</small></li>
! 
!   <ul>
!       <li>What are the semantics there? Current, just translate, is not good.
!  However, using the vob-internal CS is not really nice either, as Vob CSs
! usually are in pixels, and this would be in 10s or 100s of pixels per 
unit.</li>
  
-   </ul>
-     <li>The most general use case is the PP-like viewport. How is that 
implemented?
-  You need</li>
  
!   <ul>
!       <li>clipping</li>
!       <li>separate coordinate system for the motion of the clipping rectangle
!  and the contents</li>
  
    </ul>
  
  </ul>
!  Possible solutions:<br>
! 
! <ul>
!   <li>Separate clipping from coordinate systems. Currently, a coordinate
! system defines a clip rectangle. How about specifying the coordinate system
! to clip to when creating a (any) coordinate system, as well as the coordinate
! system into whose coordinates the given coordinate system should go.<br>
!   <small>(Benja:) This doesn't serve well in the usual viewport case, where
!          you have:
!          <ul>
!              <li>A thing you want to view (e.g. a PP paper, the contents
!                  of a cell)</li>
!              <li>A place inside that thing where your focus is (you want to
!                  view the stuff around the focus)</li>
!              <li>An area on the screen where you want to show the viewport
!                  (so that the focus is shown in the middle of the viewport,
!                  and as much of the viewed thing is shown around the focus
!                  as fits in the viewport).
!          </li></ul>
!          Calculating the position of the viewed thing relative to the viewport
!          is easier than calculating the absolute position of the viewed thing
!          on the screen: to calculate the position relative to the viewport,
!          you don't need to know the viewport's position, just the focus;
!          to calculate the absolute position on the screen, you need both,
!          essentally translating the focus coordinates by the viewport's.
!          <br><br>
!          Therefore, I think that there is no need to special-case this in
!          the API, as it's easier to do with two nested cs.<br>
! (Tuomas:) Sorry, I don't follow this argument at all. Could we start using
! (x,y,w,h) etc. notation, since the verbal description is a bit hard to follow?
! Even more so, pictures would be good...</small></li><li>A suggested 
principle: Vobs should not have to worry about clipping,
  neither in AWT nor in GL. The current system where a Vob has to set its 
cliprect
! works for really simple cases but gets inefficient and inconvenient.</li>
!   <li><tt>createCoordsys(int transformedBy, int clippedBy, Object key, 
...)</tt></li>
!   <li>0 would be default for both, i.e. no clipping, no transformation.</li>
!   <li>Unfortunately, to get the translate-and-clip effect, you'd need two
! different coordinate systems:</li>
!   <ul>
!     <li>clipping: the current one (x,y,w,h)</li>
!     <li>transforming: (x-1, y-1, 2, 2) would give the correct one. Of course,
! we'd have shortcuts for these.</li>
!     <li>OTOH, &nbsp;you could just create the clipping one and give the 
coordinates
! explicitly anyway, if that's the meaning; that would work.</li>
!      <li>What are the semantics there? Current, just translate, is not good.
! However, using the vob-internal CS is not really nice either, as Vob CSs 
usually
! are in pixels, and this would be in 10s or 100s of pixels per unit.<br>
!      (Benja:) I think use the parent cs to translate and optionally give a 
scale
!      when creating the sub-cs, and use the parent for clipping. I think this
!      serves well in the usual case.
!      </li>
! 
!   </ul>
!   <li>Clipping would work recursively:</li>
!    <li>The most general use case is the PP-like viewport. How is that 
implemented?
! You need
! 
!     </li><li>cs1 = createCoordsys(0, 0, ...)</li>
!     <li>cs2 = createCoordsys(0, cs2, ...)</li>
!     <li>would clip by both coordinate systems when cs2 used.<br>
!     </li>
!      <li>clipping</li>
!      <li>separate coordinate system for the motion of the clipping rectangle
! and the contents</li>
! 
!   </ul>
! 
!   <p>(Benja:) I thought rotation/scaling? The above is extremely easy to do by
!      putting two cs into each other, the parent being used for clipping,
!      and the child being used for the contents.</p>
! <p>(Tjl):How would you specify that? You'd have to think about the inner 
coordinate system relative to the outer, right?</p>
! <p>(Benja:) Aaah, now we get to the real discussion! Yes, that's exactly what
!             I mean. Now if you can give me a single good case where this is
!             inconvenient and your system is more convenient, you've gone a 
long
!             way in convincing me of it. <tt>;-)<br>
! </tt></p>
! <p>(Tjl:) Easy. &nbsp;Imagine a skewed, perspective coordinate system (i.e.
! using the homogeneous coordinate transformations of OpenGL). Now imagine
! e.g. putting an image behind a viewport transformed like that it so that
! you *don't* want to transform that image. Finding the inverse transformation
! there is not trivial and requires inverting a 4x4 matrix. It <b>can</b> be 
done but it's nasty. &nbsp; I can well imagine wanting to do this. Even with 
just rotations there's too much to worry about.<br>
! </p>
! <p>
! (Benja:) Ok. And you could still do the more usual case where you 
<em>want</em>
!          to think of the inner coordinate system relative to the outer: you 
can
!          still put your transformation coordsys inside your clipping 
coordsys...
! </p>
! <p>
! (Benja:) Hmmm, issue: Before hierarchical coordsys, we used coordsys 
essentially
!          as bounding boxes for vobs (ok, different in pp, through the (AFAIK)
!          complicated PP viewport mechanism). But a coordsys is actually a 
cross
!          between a box and a coordinate transformation to you, if I understand
!          correctly: you want to use the vectors inside the coordsys as the 
unit
!          vectors for transformation coordsys in your hierarchical scheme
!          (meaning that when using OrthoCoorder, you would often create 
coordsys
!          with width = height = 1, because you do not want scaling).
!          This isn't very elegant, especially because vobs aren't truly
!          (graphically) scaled by changing their coordsys' width and height... 
Hm<br>
! <br>
! (Tjl:) Of course, the API needs changing in that case. Something like<br>
! </p><tt>/* Get a coordinate system which is translated dx, dy from the given 
coordinate</tt><br>
! <tt>&nbsp;* system.</tt><br>
! <tt>&nbsp;*/</tt><tt><br>
! int translate(int transBy, int clipBy, Object key, float dx, float 
dy);</tt><br>
  <br>
! And so on. Affine coordinate systems would also have <tt>rotate</tt>, and
! with that we would actually get rid of the current problem with affine 
coordsys
! interpolation as well, where interpolation across a rotation shrinks (since
! the coefficients go linearly), getting us closer to the semantics. <br>
  <br>
- This takes us closer to a scene graph... maybe that's a good thing. It may
- be easier to explain to people that Vob coordsystems are nodes in a scenegraph
- that get identified with nodes in another scene graph.<br>
- <p>(Benja:) Starts to sound really good, but I don't completely understand 
yet.
- Care to propose a full interface (i.e., a list of *all* supported methods)?
- I think that would help me getting the "big picture" here. (Just giving the
- method signatures would probably suffice.)
- 
- 
- <p>
- 
- 
- <br>
- Transforming and clipping:<br>
- <img src="d1.png" alt="Showing an example" width="569" height="788">
- <br>
- 
-   </p>
  
  
  
  
  
-   <br>
  
  <h2>Coordinate systems</h2>
  <p>One thing that is currently not used enough with vobs is the possibility
--- 9,59 ----
  <p>Hierarchical <tt>VobScene</tt>s need some fixing.<br>
   </p>
  
! <h2>Open issues:<br>
  
!   </h2>
  
  
! <ul>
!     <ul>
  
    </ul>
  
  </ul>
! <h2>Suggested solution:</h2>
! Vobs should not have to worry about clipping,
  neither in AWT nor in GL. The current system where a Vob has to set its 
cliprect
! works for really simple cases but gets inefficient and inconvenient.<br>
  <br>
! The suggested API change is in the file coorders.java.<br>
  <br>
  
+    The most general use case is the PP-like viewport. To achieve that, you 
need
  
+     
+ <ul>
+ <li>cs1 = createCoordsys(0, 0, ...), the coordinate system of the 
frame.</li><li>cs2 = createCoordsys(0, cs1, ...), the coordinate system 
inside.</li><li>would clip by the frame coordinate systems when cs2 used.<br>
+     </li>
+ </ul>
+ Another use case is the cell content. There, <br>
+ <ul>
+   <li>cs1 = createCoordsys(0, 0, ...) the frame coordinate system</li>
+   <li>cs2 = translatedCoordsys(0, cs1, ...) the internal coordinate system<br>
+   </li>
+ </ul>
+ <ul>
+   <li>Note about cells: As discussed in Documentation/TechReports/Graphics,
+ there is a really nasty special case for cell-like things where you 
interpolate
+ them, changing the aspect ratio. Because of this, the rendering code needs
+ to either 1) look at the external coordinate system, or 2) get more 
interpolated
+ information. This is something we might want to consider.</li>
+ </ul>
  
  
+ <ul>
+   </ul><p>
+ </p>
  
  
  <h2>Coordinate systems</h2>
  <p>One thing that is currently not used enough with vobs is the possibility
***************
*** 185,188 ****
  <br>
  <br>
  <br>
! </body></html>
--- 71,75 ----
  <br>
  <br>
  <br>
! <br>
! </body></html>
\ No newline at end of file
Index: gzz/doc/pegboard/1003/coorders.java
diff -c gzz/doc/pegboard/1003/coorders.java:1.1 
gzz/doc/pegboard/1003/coorders.java:1.2
*** gzz/doc/pegboard/1003/coorders.java:1.1     Tue Sep  3 06:15:18 2002
--- gzz/doc/pegboard/1003/coorders.java Fri Sep  6 07:56:36 2002
***************
*** 1,14 ****
  
  public interface VobCoorder {
      // ... everything else the same as before,
      // except coordsys().
  
!     int translatedCoordsys(int transformedBy, int clippedBy, float x, float 
y);
!     /** As current coordsys: create
       */
!     int boxCoordsys(int transformedBy, int clippedBy, float x, float y, float 
w, float h);
  }
  
  public interface AffineVobCoorder extends VobCoorder {
!     int rotatedCoordsys(int transformedBy, int clippedBy, float angle);
  }
--- 1,20 ----
  
  public interface VobCoorder {
+ 
      // ... everything else the same as before,
      // except coordsys().
  
!     int translatedCoordsys(Object key, int transformedBy, int clippedBy, 
!                                       float x, float y);
!     /** As current coordsys
       */
!     int boxCoordsys(Object key, int transformedBy, int clippedBy, 
!                   float x, float y, float w, float h);
  }
  
  public interface AffineVobCoorder extends VobCoorder {
!     int rotatedCoordsys(Object key, int transformedBy, int clippedBy, 
!                   float angle);
!     int scaledCoordsys(Object key, int transformedBy, int clippedBy, 
!                   float scale);
  }