[Gzz-commits] gzz/doc Gzz_Memory.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Tuomas J. Lukka <address@hidden>        03/01/07 03:26:12

Modified files:
        doc            : Gzz_Memory.rst 

Log message:
        more

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/Gzz_Memory.rst.diff?tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: gzz/doc/Gzz_Memory.rst
diff -u gzz/doc/Gzz_Memory.rst:1.2 gzz/doc/Gzz_Memory.rst:1.3
--- gzz/doc/Gzz_Memory.rst:1.2  Sun Jan  5 11:16:42 2003
+++ gzz/doc/Gzz_Memory.rst      Tue Jan  7 03:26:12 2003
@@ -50,12 +50,14 @@
     vertically(100, foo, MosaicTexture, MosaicTile);
     simpler.p = MemoryConsumer.c{left} .. MemoryConsumer.c + (-150,150){1,1} 
.. MemoryConsumer.c{down};
 
-Especially the relationship between MemoryConsumer, MosaicTexture and 
MosaicTile is difficult:
-Textures consume a particular amount of memory, but MosaicTiles are the 
allocation/deallocation unit.
-
-Loading large textures takes also time; view generation should be 
instantaneous.
-Because of this, when generating views, only *requests* for textures should be 
made,
-which are granted or not, based on the state of the texture.
+Especially the relationship between MemoryConsumer, MosaicTexture and
+MosaicTile is difficult: Textures consume a particular amount of memory,
+but MosaicTiles are the allocation/deallocation unit.
+
+Loading large textures takes also time; view generation should be
+instantaneous.  Because of this, when generating views, only *requests*
+for textures should be made, which are granted or not, based on the
+state of the texture.
 
 .. UML:: memoryrequestseq
 
@@ -85,12 +87,13 @@
     ---
     horizontally(60, aaa, client, CacheFacade, RequestQueue, ImageLoader, 
CachedTexture.ghost);
 
-In the above diagram, the first call creates the request, which is loaded in 
the background,
-and results in the image having been loaded when the request is made a second 
time. The client
-is notified when the image has been loaded.
+In the above diagram, the first call creates the request, which is loaded
+in the background, and results in the image having been loaded when the
+request is made a second time. The client is notified when the image
+has been loaded.
 
-Now, in order to not constrain the evolution of the rest of the system, we 
should have the different
-loadable types pluggable.
+Now, in order to not constrain the evolution of the rest of the system,
+we should have the different loadable types pluggable.
 
 .. UML:: memorycreates
 
@@ -116,9 +119,41 @@
     horizontally(50, foo, client, CacheFacade, ImageLoader);
     vertically(100, bar, RequestHandle, foo);
 
-The class ``RequestHandle`` abstracts a single memoryconsumer, where the system
-may query it for the maximum number of bytes needed, the way the number of 
bytes can
-be scaled, and set the current memory consumption to a particular amount.
+The class ``RequestHandle`` abstracts a single memoryconsumer, where the
+system may query it for the maximum number of bytes needed, the way the
+number of bytes can be scaled, and set the current memory consumption
+to a particular amount.
+
+As an example of how this system will be tied to the rest of Gzz,
+consider PageSpans and OpenGL. The basic operation is: "get a texture
+rectangle for the given pagespan". In order to have the information
+about the relative importances of the textures come through,
+we need to give another parameter, the importance, when getting
+the texture rectangle.
+
+.. UML:: memorytexAPI
+    
+    class GLSpans "staticAPI"
+       methods
+           TexRect get(PageSpan p, float importance, Obs o)
+
+    class TexRect
+
+    class TextureImageRequest
+
+    ---
+
+Defining the importance function is not simple; this represents 
+the tradeoffs between memory use for the focus and context.
+The first, obvious quality is that the most immediate focus has priority:
+it must never be blurred to make the context sharper.
+In the other end of the scale are the spans that are not really
+visible but might become visible when the user moves; these should
+only be loaded if there's extra memory available.
+
+
+
+