gzz-commits
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tuomas J. Lukka
Subject: [Gzz-commits] gzz/doc/pegboard/1003 PEG_1003.html
Date: Tue, 27 Aug 2002 05:32:18 -0400 
CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Tuomas J. Lukka <address@hidden>        02/08/27 05:32:18

Modified files:
        doc/pegboard/1003: PEG_1003.html 

Log message:
        Try to merge - not sure if it went well

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1003/PEG_1003.html.diff?tr1=1.3&tr2=1.4&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1003/PEG_1003.html
diff -c gzz/doc/pegboard/1003/PEG_1003.html:1.3 
gzz/doc/pegboard/1003/PEG_1003.html:1.4
*** gzz/doc/pegboard/1003/PEG_1003.html:1.3     Tue Aug 27 02:07:46 2002
--- gzz/doc/pegboard/1003/PEG_1003.html Tue Aug 27 05:32:18 2002
***************
*** 2,13 ****
  <html>
  <head>
    <title>PEG 1003</title>
- 
    <meta http-equiv="content-type"
   content="text/html; charset=ISO-8859-1">
  </head>
    <body>
- 
  <h1>PEG 1003: Fix hierarchical <tt>VobScene</tt>s</h1>
  <p><i>
  Author: Tuomas Lukka
--- 2,11 ----
***************
*** 17,60 ****
   </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?<br>
!        <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.<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>The most general use case is the PP-like viewport. How is that 
implemented?
! You need
! 
    <ul>
!      <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>
! 
!   </li>
! 
  </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
--- 15,47 ----
   </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
***************
*** 82,87 ****
--- 69,121 ----
           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.
    </small>
+ 
+   <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.</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>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>
+ 
+   </li>
+ 
+ </ul>
+   <br>
+   <br>
    </li>
  </ul>
   <br>
reply via email to
[Prev in Thread] Current Thread [Next in Thread]