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 |
====================== |
====================== |
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 |
|
|
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 |
--------------------------- |
--------------------------- |
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 |
|
|
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 |
|
|
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 |
|
|