[Gzz-commits] libvob/doc/pegboard vobscene_clipping--benja/pe...

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/libvob
Module name:    libvob
Changes by:     Tuomas J. Lukka <address@hidden>        03/04/08 03:59:41

Modified files:
        doc/pegboard/vobscene_clipping--benja: peg.rst 
        doc/pegboard/vobscene_recursion--tjl: peg.rst 

Log message:
        pegging

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/libvob/libvob/doc/pegboard/vobscene_clipping--benja/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/libvob/libvob/doc/pegboard/vobscene_recursion--tjl/peg.rst.diff?tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: libvob/doc/pegboard/vobscene_clipping--benja/peg.rst
diff -u libvob/doc/pegboard/vobscene_clipping--benja/peg.rst:1.1 
libvob/doc/pegboard/vobscene_clipping--benja/peg.rst:1.2
--- libvob/doc/pegboard/vobscene_clipping--benja/peg.rst:1.1    Mon Mar 31 
05:00:04 2003
+++ libvob/doc/pegboard/vobscene_clipping--benja/peg.rst        Tue Apr  8 
03:59:41 2003
@@ -3,8 +3,8 @@
 =============================================================
 
 :Author:       Benja Fallenstein
-:Last-Modified: $Date: 2003/03/31 10:00:04 $
-:Revision:     $Revision: 1.1 $
+:Last-Modified: $Date: 2003/04/08 07:59:41 $
+:Revision:     $Revision: 1.2 $
 :Status:       Current
 
 
@@ -109,4 +109,33 @@
    that window.
 
    This method should be safe to use as the general case; it is
-   optimizations that should be the special case, used if necessary.
\ No newline at end of file
+   optimizations that should be the special case, used if necessary.
+
+- What about the interaction of stenciling in OpenGL: We do want
+  to use stencils for e.g. irregular edges, but
+  1) there are only 8 bits in most implementations, and each clip 
+  takes one bit
+  2) only one stencil operation can be specified.
+
+    RESOLVED: We can agree that we shall support four levels of clipping
+    in OpenGL and Vobs are free to use the four lower-end bits.
+    Also, the bits are always set to 1 for pass, so
+    the stencil functions NEVER, ALWAYS, EQUAL, GEQUAL, GREATER 
+    shall always work.
+
+- Can we implement clipping along with Vob Batching correctly?
+
+    RESOLVED: Surprisingly, yes, with little problems. When clip()
+    is called, all active batches need to be prepared to clip,
+    **if** a vob is placed in them after that.
+
+- If we can't clip to a nonlinear CS in a particular case, for example
+  because there is no stencil buffer, what should we do when asked
+  to do that? Exception or silent failure with artifacts?
+
+- Should the clipping exception be specified more accurately to allow
+  graceful recovery from the preceding condition?
+
+
+
+
Index: libvob/doc/pegboard/vobscene_recursion--tjl/peg.rst
diff -u libvob/doc/pegboard/vobscene_recursion--tjl/peg.rst:1.2 
libvob/doc/pegboard/vobscene_recursion--tjl/peg.rst:1.3
--- libvob/doc/pegboard/vobscene_recursion--tjl/peg.rst:1.2     Fri Apr  4 
07:34:59 2003
+++ libvob/doc/pegboard/vobscene_recursion--tjl/peg.rst Tue Apr  8 03:59:41 2003
@@ -3,8 +3,8 @@
 =============================================================
 
 :Author:   Tuomas J. Lukka
-:Last-Modified: $Date: 2003/04/04 12:34:59 $
-:Revision: $Revision: 1.2 $
+:Last-Modified: $Date: 2003/04/08 07:59:41 $
+:Revision: $Revision: 1.3 $
 :Status:   Incomplete
 
 Performance problems in PP show that we should soon make a big
@@ -17,10 +17,10 @@
 - Should we have a "VobSceneVob", i.e. a Vob that contains a different
   VobScene or some other approach?
 
-    RESOLVED: A different approach, since we want to export coordinate
-    systems from the child vobscene to the parent, in order to do
-    anchors. This cannot be done by a Vob so we need to really touch
-    the VobScene itself.
+    RESOLVED: Something like that, but extended, since we want to export
+    several coordinate systems from the child vobscene to the parent,
+    in order to do anchors. This cannot be done by a normal Vob so we need to
+    really touch the VobScene itself.
 
 - What should the efficiency demands be? Linear w.r.t. child size?
 
@@ -30,37 +30,22 @@
     to have more speed in this case.
 
     Therefore, the time should be linear w.r.t. the **rendered**
-    coordsystems of the child, but not scale with child size. This makes
+    coordsystems of the child, but constant w.r.t. child size. This makes
     life a bit more difficult internally (can't just copy a list) but
-    should be well worth it
+    should be well worth it e.g. for PP.
 
 - How do we map between coordinate systems?
 
-    RESOLVED: Undefined for now. We provide a method to translate from
-    coordinate systems of the child to the parent.
+    RESOLVED: By explicitly creating a coordinate system in the parent
+    corresponding to a coordinate system in the child by a special method..
 
-    Note that grandchildren will simply use this twice::
-
-       ... # create grandChildVobScene
-       grandChildVobSceneId = childVobScene.add(grandChildVobScene)
-       ... # create childVobScene
-       childVobSceneId = vobScene.add(childVobScene)
-           
-       childCS = childVobScene.childCS(grandChildVobSceneId, grandChildCS);
-       cs = vobScene.childCS(childVobSceneId, childCS);
-
-- Modifications?
+- Modifications to child vobscenes?
 
     RESOLVED: Using a vobscene after a child that was placed into it
     has been altered in any way **except** coordinate system parameter
     change gives undefined results for now. Possibly even crash.
 
-- Should the exported coordinate systems be defined somehow in the
-  child vobscene?
-
-    RESOLVED: No. While this is a good programming practice, and should
-    be done when using this functionality, it is probably not appropriate
-    to provide mechanisms for it.
+    This may change later.
 
 - Do we need to define coordinate systems other than the root of the
   child from the parent?
@@ -76,9 +61,14 @@
     later if necessary. This also makes matching, shouldBeRendered
     hierarchies &c inside the child easier to deal with for now.
 
+    Placing the child with a '-1' coordsys will, as a special convenience,
+    use the child's original coordinate system.
+
 - Should the child vobscene define the number of coordsys 
   in the beginning to replace with coordsys from the parent?
 
+    RESOLVED: Yes. This makes it easier to use the Vob interface.
+
 - What about coordinate system 0? Should it be special in the child
   and always correspond to cs 0 of the parent (i.e. unit transformation)?
   This is made problematic by the twim roles of coordinate system 0:
@@ -89,10 +79,60 @@
     convention: coordinate system **1** is the "root" coordinate system,
     and **0** remains the "identity" coordinate system.
 
+    The unit box of CS 1 is set to screen size, while the unit box
+    of CS 0 is (1,1)
+
 
 - How do we get the coordinate systems into the child vobscene? 
 
-- Matching?
+    RESOLVED: The child vobscene is placed as a normal Vob.
+    Normal Vobs will be extended on the Java level to what they
+    can do on the C++ level already: use arbitrary numbers of coordinate
+    systems.
+
+- Matching between different versions of a coordinate system?
+
+    RESOLVED: No, at least for now. The child VobScene is just a static
+    VobScene, rendered at the coordinates given by the parent. 
+    Nothing else.
+
+- Is a normal VobScene usable as a child vobscene? Or do we need special
+  operations?
+
+    RESOLVED: No. Too much overhead and difficulties. The correct way
+    is to create a VobSceneVob. There shall also be a call for creating
+    a coordinate system from one in the child vob.
 
 Changes
 =======
+
+The API changes are minor. 
+
+Allow N-parameter Vobs
+----------------------
+
+The current API only allows 0, 1, 2 and 3 -cs Vobs. This may not be
+enough with VobScene recursion.
+
+Add to VobPlacer (and all the classes mirroring it) the methods ::
+    
+    void put(Vob vob, int[] cs);
+    void put(Vob vob, int[] cs, int n);
+
+where ``n`` implies that the first n elements of the array should be used.
+
+VobSceneVob
+-----------
+
+A new Vob class which embeds a complete VobScene.
+
+    public class VobSceneVob {
+       /** Create a new vobscenevob from the given VobScene.
+        * The given VobScene must not be modified after this call.
+        * @param scene The VobScene
+        * @param
+        */
+       public VobSceneVob(VobScene scene, int n);
+    }
+
+