[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