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