/[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.6 by tjl, Thu Jun 12 12:50:23 2003 UTC revision 1.7 by tjl, Mon Jun 16 16:48:29 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 to vob, since  - For PageImageSpans, there are several possible mappings from span
28    there are several possible renderings: without background paper, with background paper,    to vob, since there are several possible renderings: without background
29    with halos or blurring on the background paper &c.    paper, with background paper, with halos or blurring on the background
30    Obviously, the code to go from an OpenGL texture to the rendered vob must be pluggable to allow    paper &c.  Obviously, the code to go from an OpenGL texture to the
31    for these features and future extensions in rendering of images of text.    rendered vob must be pluggable to allow for these features and future
32      extensions in rendering of images of text.
33    
34  - 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 as separate vobs
35    
36  - The coordinate system of the page in the texture is not fixed between different spans;  - The coordinate system of the page in the texture is not fixed between
37    different resolutions might be used.    different spans; different resolutions might be used.
38    
39  - unused spans need to be garbage collected and their textures freed: must be able to handle  - unused spans need to be garbage collected and their textures freed:
40    spaces with 10^6 different span images.    must be able to handle spaces with 10^6 different span images.
41    
42  - Need to be able to get width/height of the finished vob - what are its extents in the cs it will be placed to  - Need to be able to get width/height of the finished vob - what are
43      its extents in the cs it will be placed to
44    
45  - Should be able to say (optionally) that the given span is put into an important or unimportant place;  - Should be able to say (optionally) that the given span is put into
46    although this may be unnecessary if the pixel counting works and culling is used    an important or unimportant place; although this may be unnecessary
47      if the pixel counting works and culling is used
48    
49  User-visible interface  User-visible interface
50  ======================  ======================
# Line 78  The interfaces ``SpanImageFactory`` and Line 81  The interfaces ``SpanImageFactory`` and
81      vertically(90, yy, org.nongnu.libvob.Vob, SpanImageVob);      vertically(90, yy, org.nongnu.libvob.Vob, SpanImageVob);
82      vertically(90, zz, org.nongnu.alph.ImageSpan, SpanImageFactory);      vertically(90, zz, org.nongnu.alph.ImageSpan, SpanImageFactory);
83    
84  Apart from the option of creating different kinds of SpanImageFactories with different properties  Apart from the option of creating different kinds of SpanImageFactories
85  for e.g. page backgrounds, this is all the other classes need to see.  with different properties for e.g. page backgrounds, this is all the
86    other classes need to see.
87    
88  Implementation  Implementation
89  ==============  ==============
90    
91  The implementations are in ``org.fenfire.spanimages.gl`` (once an AWT implementation  The implementations are in ``org.fenfire.spanimages.gl``
92  is made, it will be in the package ``org.fenfire.spanimages.fuzzybear``).  (once an AWT implementation is made, it will be in the package
93    ``org.fenfire.spanimages.fuzzybear``).
94    
95  ImageSpan vs PageImageSpan  ImageSpan vs PageImageSpan
96  --------------------------  --------------------------
97    
98  It is reasonable to expect different treatment of Image and PageImage spans:  It is reasonable to expect different treatment of Image and PageImage
99  for PageImageSpans, we may want libpaper backgrounds and text-enhancing transformations.  spans: for PageImageSpans, we may want libpaper backgrounds and
100    text-enhancing transformations.
101    
102  ..  UML:: fenfirespansint2  ..  UML:: fenfirespansint2
103    
# Line 110  for PageImageSpans, we may want libpaper Line 116  for PageImageSpans, we may want libpaper
116      ---      ---
117      horizontally(80, xx, MuxSpanImageFactory, SpanImageFactory);      horizontally(80, xx, MuxSpanImageFactory, SpanImageFactory);
118    
119  MuxSpanImageFactory calls one factory for pageimagespans and the other for plain  MuxSpanImageFactory calls one factory for pageimagespans and the other
120  image spans.  for plain image spans.
121    
122  Repository of loaded images  Repository of loaded images
123  ---------------------------  ---------------------------
# Line 179  take care of mapping spans to OpenGL tex Line 185  take care of mapping spans to OpenGL tex
185      vertically(80, zz, SingleImage, ww);      vertically(80, zz, SingleImage, ww);
186            
187    
188  An important architectural feature is that the classes are not static: this allows  An important architectural feature is that the classes are not static:
189  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.
190    
191  Mapping Images to Paper objects  Mapping Images to Paper objects
192  -------------------------------  -------------------------------
193    
194  The libPaper paper abstraction is useful for rendering sections of the images,  The libPaper paper abstraction is useful for rendering sections of the
195  with various settings. The input should be the TexGen matrix for the paper texture,  images, with various settings. The input should be the TexGen matrix
196  and the GL texture object.  for the paper texture, and the GL texture object.
197    
198  We may want to change this interface to include the scale of the characters on the paper  We may want to change this interface to include the scale of the
199  at some point to allow better text enhancement.  characters on the paper at some point to allow better text enhancement.
200    
201  ..  UML:: fenfirespans_paper  ..  UML:: fenfirespans_paper
202    
# Line 217  at some point to allow better text enhan Line 223  at some point to allow better text enhan
223  Statistics accumulation and memory pool handling  Statistics accumulation and memory pool handling
224  ------------------------------------------------  ------------------------------------------------
225    
226  Now we come to the *raison d'etre* of this architecture:  Now we come to the *raison d'etre* of this architecture: centralized
227  centralized handling of the feedback from vobscene rendering.  handling of the feedback from vobscene rendering.  The TexAccum class in
228  The TexAccum class in Libvob is able to accumulate the approximate  Libvob is able to accumulate the approximate number of pixels rendered
229  number of pixels rendered at each mipmap level of each texture.  at each mipmap level of each texture.
230    
231  ..  UML:: fenfirespans_texaccum  ..  UML:: fenfirespans_texaccum
232    
# Line 242  number of pixels rendered at each mipmap Line 248  number of pixels rendered at each mipmap
248      ---      ---
249      q.n = PoolManager.s;      q.n = PoolManager.s;
250    
251      org.nongnu.libvob.memory.MemoryPartitioner.s + (0, -60) = PoolManager.n;      org.nongnu.libvob.memory.MemoryPartitioner.s + (0, 60) = PoolManager.n;
252    
253            
254    

Legend:
Removed from v.1.6  
changed lines
  Added in v.1.7

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