James Cloos cl...@jhcloos.com writes:
The C version does away-from-zero rounding.
MB Do you have test cases that show this? I tried using random inputs,
MB but even up to billions of iterations, I can't seem to find a set of
MB inputs where my function yields different results from yours.
Graham,
Here are the results of my performance testing. I was a bit surprised by the
results.
In gray_convert_glyph, the time is distributed as follows:
OLDNEW
render_line 20%15%
render_cubic 15%33%
render_scanline 14%10%
split_cubic6%
That is very interesting and very useful - in fact I think the more surprising
a
test is, the more useful it is. I'll have to look into your test case carefully
as well. I might not be able to do it for a day or to, though.
Where does your test data come from? Actual fonts, cooked up data, or
After trying various other fonts, I settled on using a single large (14,000
glyphs; 800,000 Bezier curves) CID-keyed Type 1 font, which seemed to show
pretty average behaviour.
I'm working on an implementation of something like Hain's algorithm now.
It'll be interesting to see how it
With 14,000 glyphs, I imagine that's a CJK font. I think there might be
different characteristics from a typical Latin font. I think we also ought to
try out a similar number of Latin glyphs, which could be done by rasterizing
all
the glyphs in a Latin font at varying sizes and rotations. In
I've now implemented something based on Hain's research and it seems to be
measurably faster than previous FT approaches. I have used Hain's paper (now
available from http://tinyurl.com/HainBez) to provide some sensible heuristics
rather than implement all his stuff in detail, and done so
Here are some test results with Latin fonts (40 thousand curves from fonts at
various point sizes).
Trace results:
CJK CJK CJK LATIN LATIN
OLD NEW HAINNEW HAIN
MB == Miles Bader mi...@gnu.org writes:
MB Hm, are you sure that's not backwards? When I tried the git C version[*],
MB as well as your most recent FT_MulFix_x86_64, it returned 0x8506...
Odd. Adding your algo to my test app, I get:
7AFA8000, , 8505, 8505, 8506
#
James Cloos cl...@jhcloos.com writes:
Since FT's C version uses longs, though, this:
int another (long a, long b) {
long r = (long)a * (long)b;
long s = r 31;
return (r + s + 0x8000) 16;
}
That's not correct though, is it? The variable s should be the all
sign portion of the
