/[fenfire]/fenfire/docs/design_SpanImages.rst
ViewVC logotype

Diff of /fenfire/docs/design_SpanImages.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.8 by tjl, Sat Jun 21 13:56:14 2003 UTC revision 1.9 by tjl, Mon Jun 23 12:28:50 2003 UTC
# Line 24  Requirements Line 24  Requirements
24    
25  There are several details which will make life difficult:  There are several details which will make life difficult:
26    
27  - For PageImageSpans, there are several possible mappings from span  - For ``PageImageSpan`` objects, there are several possible
28      mappings from span
29    to vob, since there are several possible renderings: without background    to vob, since there are several possible renderings: without background
30    paper, with background paper, with halos or blurring on the background    paper, with background paper, with halos or blurring on the background
31    paper &c.  Obviously, the code to go from an OpenGL texture to the    paper &c.  Obviously, the code to go from an OpenGL texture to the
32    rendered vob must be pluggable to allow for these features and future    rendered vob must be pluggable to allow for these features and future
33    extensions in rendering of images of text.    extensions in rendering of images of text.
34    
35  - Both the whole page and fragments of the page may be desired as separate vobs  - Both the whole page and fragments of the page may be desired
36      as separate vobs
37    
38  - The coordinate system of the page in the texture is not fixed between  - The coordinate system of the page in the texture is not fixed between
39    different spans; different resolutions might be used.    different spans; different resolutions might be used.
# Line 81  The interfaces ``SpanImageFactory`` and Line 83  The interfaces ``SpanImageFactory`` and
83      vertically(90, yy, org.nongnu.libvob.Vob, SpanImageVob);      vertically(90, yy, org.nongnu.libvob.Vob, SpanImageVob);
84      vertically(90, zz, org.nongnu.alph.ImageSpan, SpanImageFactory);      vertically(90, zz, org.nongnu.alph.ImageSpan, SpanImageFactory);
85    
86  Apart from the option of creating different kinds of SpanImageFactories  Apart from the option of creating different ``SpanImageFactory`` objects
87  with different properties for e.g. page backgrounds, this is all the  with different properties for e.g. page backgrounds, this is all the
88  other classes need to see.  other classes need to see.
89    
# Line 92  The implementations are in ``org.fenfire Line 94  The implementations are in ``org.fenfire
94  (once an AWT implementation is made, it will be in the package  (once an AWT implementation is made, it will be in the package
95  ``org.fenfire.spanimages.fuzzybear``).  ``org.fenfire.spanimages.fuzzybear``).
96    
97  ImageSpan vs PageImageSpan  ``ImageSpan`` vs ``PageImageSpan``
98  --------------------------  ----------------------------------
99    
100  It is reasonable to expect different treatment of Image and PageImage  It is reasonable to expect different treatment of
101  spans: for PageImageSpans, we may want libpaper backgrounds and  ``ImageSpan`` and ``PageImageSpan`` objects:
102    for ``PageImageSpan`` objects, we will often want libpaper backgrounds and
103  text-enhancing transformations.  text-enhancing transformations.
104    
105  ..  UML:: fenfirespansint2  ..  UML:: fenfirespansint2
# Line 109  text-enhancing transformations. Line 112  text-enhancing transformations.
112      class MuxSpanImageFactory      class MuxSpanImageFactory
113          jlink          jlink
114          realize SpanImageFactory          realize SpanImageFactory
115    
116        foo = assoc MuxSpanImageFactory role(mux) - multi(1) role(imagefact) SpanImageFactory
117        bar = assoc MuxSpanImageFactory role(mux) - multi(1) role(pageimagefact) SpanImageFactory
118        ---
119        SpanImageFactory.c = (0,0);
120        horizontally(80, xx, SpanImageFactory, MuxSpanImageFactory);
121    
122        sk=-.35;
123        foo.p = (MuxSpanImageFactory.c{sk,1}..SpanImageFactory.c{sk,-1});
124        bar.p = (MuxSpanImageFactory.c{sk,-1}..SpanImageFactory.c{sk,1});
125    
126    The ``MuxSpanImageFactory`` object
127    delegates calls to one factory for ``PageImageSpan`` objects
128    and to the other
129    for plain ``ImageSpan`` objects.
130    
131    Caching of ``SpanImageVob`` objects
132    -----------------------------------
133    
134    The caching is taken care by another step added to the chain:
135    
136    .. UML:: fenfirespans_caching
137    
138        jlinkpackage org.fenfire.spanimages
139        class SpanImageFactory "abstract"
140            jlink
141    
142        class CachingSpanImageFactory
143            realize SpanImageFactory
144            jlink
145          fields          fields
146              SpanImageFactory imageFactory              Map cache
147              SpanImageFactory pageImageFactory  
148        foo = assoc CachingSpanImageFactory role(cache) - multi(1) role(orig) SpanImageFactory
149    
150      ---      ---
151      horizontally(80, xx, MuxSpanImageFactory, SpanImageFactory);      SpanImageFactory.c = (0,0);
152        horizontally(80, xx, SpanImageFactory, CachingSpanImageFactory);
153        sk = -.35;
154        foo.p := (CachingSpanImageFactory.c{sk,1}..SpanImageFactory.c{sk,-1});
155    
156  MuxSpanImageFactory calls one factory for pageimagespans and the other  The ``CachingSpanImageFactory`` will first check its cache and
157  for plain image spans.  only if it does not find the object cached will it recreate it.
158    
159  Repository of loaded images  Repository of loaded textures
160  ---------------------------  -----------------------------
161    
162  The class twin classes  The twin classes
163  ``PageScrollBlockImager`` and ``ImageScrollBlockImager``  ``PageScrollBlockImager`` and ``ImageScrollBlockImager``
164  take care of mapping spans to OpenGL textures (mipzips).  take care of mapping spans to OpenGL textures (mipzips).
165    
# Line 172  take care of mapping spans to OpenGL tex Line 209  take care of mapping spans to OpenGL tex
209            
210    
211  An important architectural feature is that the classes are not static:  An important architectural feature is that the classes are not static:
212  this allows us to, e.g, plug in filters for the images of PageImageSpan.  this allows us to, e.g, plug in filters for the images of ``PageImageSpan``.
213    
214  The Single Image class  The Single Image class
215  ----------------------  ----------------------
# Line 186  is ``SingleImage``. Line 223  is ``SingleImage``.
223    
224      class SingleImage      class SingleImage
225          jlink          jlink
         realize org.nongnu.libvob.gl.GL.StatsCallback  
226          assoc compos multi(1) - multi(1) org.nongnu.libvob.gl.MipzipLoader          assoc compos multi(1) - multi(1) org.nongnu.libvob.gl.MipzipLoader
227          assoc compos multi(1) - multi(1) org.nongnu.libvob.gl.GL.TexAccum          assoc compos multi(1) - multi(1) org.nongnu.libvob.gl.GL.TexAccum
228          fields          fields
# Line 249  Statistics accumulation and memory pool Line 285  Statistics accumulation and memory pool
285  ------------------------------------------------  ------------------------------------------------
286    
287  Now we come to the *raison d'etre* of this architecture: centralized  Now we come to the *raison d'etre* of this architecture: centralized
288  handling of the feedback from vobscene rendering.  The TexAccum class in  handling of the feedback from vobscene rendering.  The ``TexAccum`` class in
289  Libvob is able to accumulate the approximate number of pixels rendered  Libvob is able to accumulate the approximate number of pixels rendered
290  at each mipmap level of each texture. This is collected by the SingleImage class.  at each mipmap level of each texture. This is collected
291    by the ``SingleImage``
292    .
293    
294  Because the ``MemoryPartitioner`` approach is a bit hard for us to interface with here  Because the ``MemoryPartitioner`` approach is a bit hard
295    for us to interface with here
296  (the quality - calling time stuff is not optimal for us) we have  (the quality - calling time stuff is not optimal for us) we have
297  our own partitioner.  our own partitioner.
298    
299  The PoolManager keeps a set of active textures.  The ``PoolManager`` keeps a set of active textures.
300    
301  ..  UML:: fenfirespans_texaccum  ..  UML:: fenfirespans_texaccum
302    

Legend:
Removed from v.1.8  
changed lines
  Added in v.1.9

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26