[cairo] GPU accelerated tessalation
Bill Spitzak
spitzak at d2.com
Fri Aug 5 14:02:33 PDT 2005
A very similar sketch was presented at Siggraph:
Efficient Magnification of Bi-Level Textures
Standard tri-linear filtering blurs road signs and similar items
excessively. We use a single-channel MIP map of small size and an
efficient pixel shader to significantly improve bi-level textures.
Jörn Loviscach
Hochschule Bremen
jlovisca (at) informatik.hs-bremen.de
Their technique is decidely low-tech compared to yours. The biggest
disadvantage is that they completly ignore the thin objects and sharp
corners that you mention, and if you blow up the image a lot you get
rounded corners. I also question whether it really works when the
texture scaling approaches 1:1. The advantage is that their method works
on very old graphics cards. I was also pretty impressed with the results
as my initial feeling is that this is a hack that would never work, but
in fact it produces very nice letters from very low-resolution textures.
Their method is simply to make a grayscale texture and then threshold it
at .5 after it has been enlarged to produce the outline. Antialiasing is
done by replacing the threshold by a very steep ramp depending on the
current scale (slope = 1/(scale*3)). The original textures look a lot
like grayscale images of the letters, with some extra pixels at the
corners as though it had been run through a sharpening filter.
To make glyphs smaller they use mipmaps where all the smaller sizes are
normal images (not designed to be looked up with the threshold
function). They gradually blend the threshold ramp down to the identity
function at 1/2 size. This avoids any need to mess with the hardware's
texture lookup functions.
My opinion is that these schemes are *extremely* important and Cairo
should not ignore them. The most important effect is that any api where
a font+transform is treated as a single object is going to be hurting
really bad when trying to implement this. Programs may assumme that
creating vast numbers of different font+transforms is very efficient,
resulting in backends having to use huge amounts of memory to store all
the combinations it encounters. I recommend that any design keep the
font and transform seperate. If a glyph cache is necessary there should
be a large single cache, indexed by hashing the font+transform together,
rather than attempting to make caches per-font.
c.mench at free.fr wrote:
> Hello all,
>
> i just wanted to point out a research work that could
> be the next step after cairo1 + Glitz.
>
> Here it is presented a way to not just only GPU accelerate
> the rasterisation but also the tessalation of the vector
> primitives.
>
> link:
> www.loria.fr/~levy/publications/papers/2005/VTM/vtm.pdf
>
> abstract:
> "This paper presents VTMs (Vector Texture Maps), a novel representation of
> vector images that can be used as a texture by the GPU for real-time rendering.
> A VTM decomposes texture space into different regions, represented in an
> analytic way, by a set of implicit degree 3 polynomials. Each region can be
> rendered by a different fragment shading function. Accurate anti-aliasing is
> performed in real-time, based on an estimate of fragment coverage. As a
> consequence, infinite zooming can be applied without any pixel discretization
> artifact. Based on a hierarchical data structure, our representation has low
> memory requirements. Its versatility is demonstrated in various settings,
> including a font engine completely implemented in the GPU."
>
>
> what do you think of it?
>
> thanks for reading
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.freedesktop.org/mailman/listinfo/cairo
>
More information about the cairo
mailing list