[Gzz-commits] manuscripts/Paper paper.tex

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Tuomas J. Lukka <address@hidden>        03/03/31 08:35:21

Modified files:
        Paper          : paper.tex 

Log message:
        reorg-unlock

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/Paper/paper.tex.diff?tr1=1.88&tr2=1.89&r1=text&r2=text

Patches:
Index: manuscripts/Paper/paper.tex
diff -u manuscripts/Paper/paper.tex:1.88 manuscripts/Paper/paper.tex:1.89
--- manuscripts/Paper/paper.tex:1.88    Mon Mar 31 07:35:50 2003
+++ manuscripts/Paper/paper.tex Mon Mar 31 08:35:21 2003
@@ -711,8 +711,6 @@
 
 \section{Hardware-accelerated implementation}
 
-TJL
-
 In this section, we discuss our hardware-accelerated implementation
 (libpaper)
 of unique backgrounds (papers).
@@ -723,8 +721,9 @@
 We have found that setting the parameters hierarchically
 produces the best results: the parameters for different passes
 should depend on hyperparameters randomly selected for entire paper.
-
-XXX REASONING: YELLOW SQUARE, RED TRIANGLE
+This is in accordance with the discussion about \cite{olson02vstm}
+above: the hyperparameters limit the number of different features
+that are rendered onto one texture.
 
 Our current parameter hierarchy is shown in 
 Fig.~\ref{figpipeline}. The individual parameters are
@@ -745,14 +744,38 @@
 
 \subsection{Rationale for a Fragment-based implementation}
 
-Our implementation needs to support complicated mappings
+One major goal for the
+implementation is to support complicated mappings
 between paper and screen coordinates, such as fisheye distortion.
-To make this simple, all processing to obtain shapes on the paper 
+To make this simple, all processing when rendering the background texture
 must be done on the fragment level after the texture accesses, i.e., we cannot 
use
-procedural geometry.
+procedural geometry except if pre-rendering the background into a texture.
+
+However, pre-rendering each texture is likely to be too time- and 
memory-consuming
+if there are dozens of different documents visible at the same time, 
+so 
+we shall limit ourselves to pure fragment-based rendering in this article.
+However, if a single background  covers large areas of the screen,
+pre-rendering may increase performance considerably, and therefore
+our implementation does support 
+two rendering modes with different
+tradeoffs. In the direct mode, 
+small, static basis textures are used, which requires 2-3 passes
+with all texture units enabled. 
+In the 
+pre-rendered mode,
+rendering
+requires 1 pass with only one texture unit,
+but the repeating unit of the texture
+has to be
+pre-rendered into a texture of its own.
+To achieve a satisfactory image quality in zooming
+with pre-rendering,
+a relatively large texture has to be used for each background; 512x512 is not 
really sufficient.
 
 Plain OpenGL 1.3 does not by itself provide enough flexibility in the fragment
-pipeline to allow the flexible generation of features.
+pipeline to allow for generating features nonlinearly from
+the basis textures.
 Because of this, and the availability of stable Linux drivers,
 our main platforms are NV10, i.e., OpenGL 1.3 + 
 \url{GL\_\hyp NV\_\hyp register\_\hyp combiners},
@@ -778,19 +801,6 @@
 % % How is it used?
 % % XXX 
 
-We have two rendering modes with different
-tradeoffs: direct, where
-small, static basis textures are used, which requires 2-3 passes
-with all texture units enabled, and
-pre-rendered, where the repeating unit of the texture
-is pre-rendered into a larger texture of its own, and rendering
-requires 1 pass with only one texture unit.
-To achieve a satisfactory image quality in zooming
-with the latter approach,
-a relatively large texture has to be used; 512x512 is not really sufficient.
-
-If using only the direct mode, it would be possible to use procedural geometry
-when generating the texture as well, but 
 
 
 \subsection{Colors}