On Fri, 25 Jan 2002 19:33:53 -0500, Seer wrote: > >When rasterizing a rotated glyph, is it efficient to specify >different rotations for individual glyphs within a single >font? It seems that the rotation is part of the font name, >but hopefully the font file is not wholly reparsed for every >different angle a glyph is rendered at. (This may came into >play when rendering text along curves, the rasterization >and font parsing should involve no more work for printing >ABCDE across a bezier curve than in a straight line...
In my view, rotated text is sufficiently uncommon that any non-trivial optimization is not worth the effort. If I draw a capital A at every angle from 0 to 359 degrees, I would not be at all surprised to find the font file reparsed 360 times. >The last question is: if every app is doing rasterization, >its seems that alot of duplicate work is being done. A >daemon with a version of Xft font manager could be running >which did the rasterizition and caching. CPUs today are FAST. Rasterization happens to be something CPUs are good at. It is not at all clear that the penalty incurred in duplicate rasterization is outweighed by the additional code complexity and cost of caching and interprocess communication. >Imagine >having 20 windows open and the titlebar font is exotic kanjis >that each app is rasterizing them separatly, Instead they >could be rasterized once and given to the apps by read >only shared memory or some such thing. But you never need to render all 20 titlebars at once. The penalty is amortized over the life of the session. I think you are overestimating the cost of rasterization and the gain of caching. Windows went through a period where all the driver writers implemented on- board font caching under the blind assumption that it had to improve Winbench scores. Around 1994 or so, people were finally doing comparative benchmarks with and without caching, and discovered to their surprised that text performance was almost always better without it. The Windows font architecture is quite a bit different, of course, but the lesson is a valuable one. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
