[Gzz-commits] gzz/Documentation/Manuscripts/Irregu irregu.tex

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Tuomas J. Lukka <address@hidden>        02/11/13 07:23:47

Modified files:
        Documentation/Manuscripts/Irregu: irregu.tex 

Log message:
        Prosifying

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/Manuscripts/Irregu/irregu.tex.diff?tr1=1.34&tr2=1.35&r1=text&r2=text

Patches:
Index: gzz/Documentation/Manuscripts/Irregu/irregu.tex
diff -u gzz/Documentation/Manuscripts/Irregu/irregu.tex:1.34 
gzz/Documentation/Manuscripts/Irregu/irregu.tex:1.35
--- gzz/Documentation/Manuscripts/Irregu/irregu.tex:1.34        Wed Nov 13 
05:43:14 2002
+++ gzz/Documentation/Manuscripts/Irregu/irregu.tex     Wed Nov 13 07:23:44 2002
@@ -55,74 +55,63 @@
 - windows, frames
 - porthole
 
+(refs from kramer94translucentwindows)
+Sutherland: SketchPAD!?!?!?!
+Kay: Flex, Smalltalk?!
+
+Xerox PARC frames
+
 - very little variation
     
 Even in systems that modify the conventional windowing model, 
 such as the 
-
-3D window manager "Task Wall" \cite{robertson00task}
-and Elastic Windows\cite{kandogan96elastic,kandogan97elastic}, 
-3D book of web pages (WebBook)\cite{card96webbook},
-organization of documents: 
LifeStreams\cite{freeman95lifestreams,freeman96lifestreams},
-mUltimo3D\cite{liu-threedimensional}
-SPI hyperdocument presentation interface\cite{hannemann93hyperdocument}
-
-the PAD\cite{perlin93pad} zoomable interface and its descendants,
-PAD++\cite{bederson96padpp,fc-zooming,bederson98implementing} 
-and Jazz\cite{bederson00jazz}.
-and flip zooming\cite{lars97focus}
-
+3D window manager Task Wall\cite{robertson00task},
 Data mountain\cite{robertson98data}
-BookMap system of integrating navigational aids\cite{hascoet00navigationaids}
-
-Even the distortion-oriented Document Lens\cite{robertson93documentlens}
-uses rectangular shapes... 
-as does the continuous zoom system in \cite{bartram95continuouszoom}
-
-
-The non-rectangularly stretching 3dps\cite{carpendale96multiscale}
-still is contained in a rectangular window.
+Elastic Windows\cite{kandogan96elastic,kandogan97elastic}, 
+3D WebBook\cite{card96webbook}, % real-book look-a-like
+LifeStreams\cite{freeman95lifestreams,freeman96lifestreams}, % Organizing docs 
on streams
+mUltimo3D\cite{liu-threedimensional}, % 
+SPI hyperdocument presentation interface\cite{hannemann93hyperdocument}, %
+PAD\cite{perlin93pad}, its descendants %  zoomable interface and its 
descendants,
+PAD++\cite{bederson96padpp,fc-zooming,bederson98implementing}
+and Jazz\cite{bederson00jazz},
+flip zooming\cite{lars97focus},
+BookMap\cite{hascoet00navigationaids},
+the continuous zoom system in \cite{bartram95continuouszoom}
+and
+the Document Lens\cite{robertson93documentlens}
+the viewports are squarely rectangular. % XXX !!! ;^) 
+%The non-rectangularly stretching 3dps\cite{carpendale96multiscale}
+% still is contained in a rectangular window, and
+As an extreme example,
+in \cite{carpendale01presspace}, which deals with fisheye magnification, 
+non-rectangular regions are magnified,
+but only rectangular regions are ``lifted off'' the original plane to become 
+their own viewports,  
+
+
+This list is not intended as a criticism of the above references; 
+the work done therein is first-class and focused on other aspects of the user 
interface. 
+What we are trying to demonstrate the dominance of rectangular,
+framed viewports.
+Indeed, the only references we found in the literature where
+non-rectangular viewports are actually used are 
\cite{kramer94translucentwindows} and \cite{bier93toolglass}.
+XXX go through carefully, explain here
 
 The Perspective Wall\cite{mackinlay91perspectivewall} 
-bends the rectangular basic shape
-
-In \cite{carpendale01presspace}, non-rectangular regions are magnified,
-but only rectangular regions are ``lifted off'' the original plane, 
-
-
-These are not criticisms of the above references; the work done therein 
-is first-class. What we are trying to demonstrate is that rectangular,
-framed cutouts dominate...
-
-Only articles we found \cite{kramer94translucentwindows}
-and Toolglasses \cite{bier93toolglass}.
+bends the rectangular basic shape, ...
 
 ---
 
 Reasons: - using mostly graph or 2D structure
 
-
-the viewports to the 
-
 Practical reasons: efficiency, ease of implementation
 
-all 
-
-but still windows and viewports completely
-      rectangular
-
-?
-
-    - document wall?!
-    - fisheye
-    - ? others --- mostly rectangular, though
-
-Xerox PARC frames
-
 
-Non-rectangular window shapes technically possible but not
+Non-rectangular window shapes technically \cite{XSHAPEEXT}
+possible but not
 used except for some special effects such as a
-round clock, and amusements such as shooting holes in windows or ....
+round clock, and amusements such as shooting holes in windows \cite{XBLAST} or 
....
 or animated ``agents''\cite{andre98employing} such as the Office Assistants
 of Microsoft Office.
 
@@ -196,13 +185,26 @@
 (we shall not be concerned with occlusion by other graphical objects: we shall 
only
 concentrate on the basic characteristics of the viewport).
 
-- fundamental change of model: instead of *framing* the region of paper, 
-  we *tear* it out of the paper.
-
-In the following sections,
+Viewports are used because the computer screen is finite and we need to be able
+to see a part of the canvas in more detail.
+Indeed, the conventional metaphor for representing viewports {\em is} the 
computer screen: 
+a rectangular region of pixels surrounded by a frame.
+The frame is not affected by the motion of the contents of the viewport.
+
+Tearing, as we propose it, is a different metaphor for viewports.
+Instead of showing a virtual computer screen showing a part of the canvas,
+we show a piece torn off the canvas. 
+
+In the following subsections, we first discuss why tearing is desirable (and 
different
+from the usual viewports), then the details of the design and finally the 
algorithmic side. The next section concentrates
+on implementing these algorithms at an interactive frame rate.
 
 \subsection{Rationale ``Why?''}
 
+The important difference is that
+the edge is not a different object; the ``object'' is simply the torn piece.
+
+
 A smooth rectangular or elliptical frame with scrollbars
 can make small viewports seem claustrophobic. 
 One reason for this is that the frame is often visually too small for its 
contents
@@ -218,11 +220,6 @@
 The torn edge separates itself visually from the content, alleviating
 the visual tension...
 
-Need to maintain illusion: ``we see a piece of the canvas'', not ``we see the 
canvas through
-a hole''.
-If edge does not ripple, claustrophobia comes back! Again, shaped thing PLACED 
on top of canvas,
-not part of canvas!
-
 The irregularity of the edge allows a some of the context of the viewport to 
be partially
 seen.
 
@@ -240,34 +237,56 @@
 
 \subsection{Detailed design ``What?''}
 
-- distinguishing between edges of paper and the viewport useful
-- edge of paper = line, edge of viewport = torn
-- motion: mustn't look like a "window" sliding on top of paper, but
-  like re-gluing and tearing away a different part of the paper.
+In order to create and maintain the illusion: ``we see a piece of the 
canvas'', 
+instead of ``we see the canvas through a hole'', the motion must be carefully 
designed.
+When the viewport moves on the canvas, it 
+mustn't look like a (rectangular or irregular) "window" sliding on top of 
paper, but
+instead something like re-gluing and tearing away a different part of the 
paper.
+To get the correct picture, imagine an animation where the first frame is a 
given
+torn piece of paper, the next frame is what would have happened if we had torn 
the paper
+slightly differently etc. Since the paper would have the same weak points, 
+the shapes of the nearby tears would resemble each other.
+In particular, if the edge moves parallel to the (overall) direction of the 
edge,
+the shape should remain the same: see Fig.~xxx.
+
+As to the graphical appearance of the torn viewports, 
+there are several reasons to go for nonphotorealistic rendering:
+\begin{itemize}
+\item The ``out-of-band'' semantic information\cite{XXX}: this is {\em not} 
trying to be
+and behave like a real piece of paper. The motion should thus be easier to 
understand.
+\item Overall clarity. The seminal paper of Saito and 
Takahashi\cite{saito90comprehensible} 
+introduces non-photorealistic image-space transformations for this very 
purpose. GUIs
+usually are non-photorealistic anyway.
+\end{itemize}
 
-- natural visualisation of a piece of a large paper\\
-- in a computer user interface a piece of paper can be torn without destroying 
the original\\
+Thus, instead of trying to draw a realistic torn piece of paper, we can just
+draw the silhouette edge\cite{XXX}.
 
-- the movement should be visualized in a comprehensible way\\
-- the torn shape of a point on an edge should be a continuous function of the 
point's location on the paper\\
-- the function should change slowly enough so that the dot product of movement 
direction and edge normal
-  is visible as the ``rippling speed''
+For the edge thickness, scaling it with the scale of the paper is not good
+(too photorealistic...), but neither is a constant width, which ...
+Square root XXX refs: stroke scaling in pen drawings?
 
 
-Non-photorealism: easier to understand motion; photorealistic would seem 
bizarre.
+Edge shapes: attached and sprinkled and intermediates.
 
-porthole
+Finally, there is the question of what should happen when the viewport reaches 
the edge
+of the canvas.
+- distinguishing between edges of paper and the viewport useful
+    - edge of paper = line, edge of viewport = torn
 
-- draw edge
 
-For the edge thickness, scaling it with the scale of the paper is not good
-(too photorealistic...), but neither is a constant width, which ...
-Square root
 
-Edge shapes: attached and sprinkled and intermediates.
 
 \subsection{Algorithm ``How?''} 
 
+In this subsection, we formulate the design criteria of the preceding section 
mathematically
+to obtain a simple algorithm with the desired properties and an interesting 
graphical explanation
+for the algorithm.
+
+- the torn shape of a point on an edge should be a continuous function of the 
point's location on the paper\\
+- the function should change slowly enough so that the dot product of movement 
direction and edge normal
+  is visible as the ``rippling speed''
+
 The jagged shape is defined by a surface $(x, y, f(x,y))$,
 where $0 \le f(x,y) \le 1$ and $(x, y, 1/2)$ is paper location.
 The shape of an edge torn along a line is obtained by intersecting
@@ -294,7 +313,13 @@
 the feature sets of other APIs and manufacturers
 are quite similar.
 
-Knuth \& John Hobby ref. 
+There are two basic alternatives for drawing the shape: either
+by using geometry to draw the jagged edge segment by segment,
+or by using a texture to draw a longer stretch at one time.
+We have chosen the latter approach as the more likely one to
+yield an acceptable performance. Also, it is easier to avoid
+aliasing artifacts in the texture approach..
+
 
 \subsection{Drawing the shape}
 
@@ -348,8 +373,6 @@
 
 
 
-%      Takafumi Saito , Tokiichiro Takahashi, NC machining with G-buffer 
method, ACM SIGGRAPH Computer Graphics, v.25 n.4, p.207-216, July 1991
-
 
 Most work to date 
 on NPR silhouette edges concerns either
@@ -499,6 +522,10 @@
 
 \section{Conclusions}
 
+frequencies: only low/high in frames
+
+interaction with libpaper!!!
+
 - Ripples take up space?
     - not really, and rounder shapes free it. In some cases, uneven
       edge could even be seen as being used {\em twice}
@@ -507,12 +534,22 @@
     - for totally free zooming, not so good
 
 - no scrollbars
+porthole
+
 
     - not needed in proper focus+context UI: if we're interested
       we just *GO* there and it expands. Can have scrollbars on
       "main" focus view
 
-frequencies: only low/high in frames
+- incompatible with other types of things:
+
+    - toolbars, menus
+       
+       - if using one zoomed window, using a smooth frame is fine
+         since the "extra object" of the frame is not there: it is
+         the computer screen.
+
+    - click - and - switch
 
 TODO: usability tests