Re: [ft] FT_Outline_Render makes different bitmaps in 32-bit and 64-bit programs?
Hi,
It seems that this bug appears since a change between 2.3.9 and 2.3.10:
The change does not seem to have different effect between 32-bit and
64-bit systems, so I'm afraid there is unknown bug related with overflow
or anything like that, and 64-bit system doesn't fall in it occasionally.
I will try to fix, although I cannot start quickly (due to forthcoming
JTC1/SC2/WG2 IRG meeting in Macao). Thank you for finding this issue.
Regards,
mpsuzuki
commit 0409ef32686188c1947298e0fca9fbeadd23c1c3
Author: Werner Lemberg w...@gnu.org
Date: Thu Jun 11 17:32:31 2009 +0200
Increase precision for B/W rasterizer.
* src/raster/ftraster.c (Set_High_Precision): Add two more bits to
the precision. This corrects rendering of some small glyphs, for
example, glyph `xi' in verdana.ttf at 13 ppem. Testing with ftbench
on my GNU/Linux box I don't see a performance degradation.
diff --git a/ChangeLog b/ChangeLog
index 36b6210..6edf105 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-06-11 Werner Lemberg w...@gnu.org
+
+ Increase precision for B/W rasterizer.
+
+ * src/raster/ftraster.c (Set_High_Precision): Add two more bits to
+ the precision. This corrects rendering of some small glyphs, for
+ example, glyph `xi' in verdana.ttf at 13 ppem. Testing with ftbench
+ on my GNU/Linux box I don't see a performance degradation.
+
2009-06-08 Michael Zucchi not...@gmail.com
Handle FT_STROKER_LINECAP_BUTT.
diff --git a/src/raster/ftraster.c b/src/raster/ftraster.c
index 12a8dff..5ade13b 100644
--- a/src/raster/ftraster.c
+++ b/src/raster/ftraster.c
@@ -588,9 +588,9 @@
{
if ( High )
{
- ras.precision_bits = 10;
- ras.precision_step = 128;
- ras.precision_jitter = 24;
+ ras.precision_bits = 12;
+ ras.precision_step = 256;
+ ras.precision_jitter = 50;
}
else
{
Tom Bishop, Wenlin Institute wrote:
On Oct 25, 2010, at 10:05 PM, suzuki toshiya wrote:
Hi,
Since 2.3.8? I'm really interested in, because I had committed
many changes for 16-bit/64-bit platforms between 2.3.9 and 2.3.10.
In your observation, 2.3.8 is ok but 2.3.9 is not ok?
Or, 2.3.7 is ok but 2.3.8 is not ok?
This problem didn't occur with 2.3.8, but it does occur with 2.4.2.
Unfortunately, I haven't tried any versions in between.
Yours,
Tom
文林 Wenlin Institute, Inc.Software for Learning Chinese
E-mail: wen...@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FT_Outline_Render makes different bitmaps in 32-bit and 64-bit programs?
It seems that this bug appears since a change between 2.3.9 and 2.3.10: [...] Thanks in advance for investigating the problem. Since I don't have access to a 64bit system, I unfortunately can't help much. Werner ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FT_Outline_Render makes different bitmaps in 32-bit and 64-bit programs?
The bug appears to be here in ftraster.c:
/* FMulDiv means `Fast MulDiv'; it is used in case where `b' is */
/* typically a small value and the result of a*b is known to fit into */
/* 32 bits. */
#define FMulDiv( a, b, c ) ( (a) * (b) / (c) )
Evidently ...known to fit into 32 bits is overly confident, especially when
precision_bits = 12 (rather than 10 or 6).
Changing to
#define FMulDiv FT_MulDiv
(same as SMulDiv) solves the bug. For more information, you can make it a
function:
static long FMulDiv(long a, long b, long c)
{
long fast = ( (a) * (b) / (c) );
long slow = FT_MulDiv(a, b, c);
if (fast != slow) {
printf(Problem in FMulDiv (%ld, %ld)\n, fast, slow);
}
return slow;
}
For the test program, there are many reports where fast and slow differ only
slightly:
Problem in FMulDiv (162, 163)
Problem in FMulDiv (461, 462)
Problem in FMulDiv (49, 50)
...
But also some reports where the difference is huge:
Problem in FMulDiv (-308386, 934370)
Problem in FMulDiv (15151, -107087)
...
Maybe the solution could be optimized for speed by determining which calls to
FMulDiv() are failing badly, and changing them to SMulDiv(), while retaining
the old FMulDiv() where appropriate; but how one can assume such a limitation
on the size of path coordinates? And is FT_MulDiv() really slow enough to make
a big difference?
By the way, I noticed a few other things in ftraster.c:
(1) ras.precision_mask is never used. The macros like FLOOR() use
-ras.precision; maybe they were supposed to use ras.precision_mask.
(2) ULong is never used.
(3) Changing Int, Short, Long, and *PLong all to int32_t, and changing UInt,
UShort, and *PUShort all to uint32_t seems to make no difference to the
behavior when running as 32-bit, but when running as 64-bit, it crashed with
EXC_BAD_ACCESS at this line in Draw_Sweep():
P-countL = (UShort)( P-start - min_Y );
-- because P wasn't a valid pointer; P-link had become corrupted. This line in
Finalize_Profile_Table() is suspicious:
p-link = (PProfile)( p-offset + p-height );
Note p-offset is type PLong, so the assumption seems to be made that
sizeof(PProfile) == sizeof(Long), i.e., sizeof(struct TProfile_ *) ==
sizeof(Long), or in general, sizeof(void *) == sizeof(Long). Here's one example
where Freetype does need 64-bit items, to store pointers when running in a
64-bit program; but it seems problematic to assume a pointer is the same size
as any type of integer. If p-offset is used for storage of PProfile, shouldn't
its type be PProfile rather than PLong?
Yours,
Tom
文林 Wenlin Institute, Inc.Software for Learning Chinese
E-mail: wen...@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FT_Outline_Render makes different bitmaps in 32-bit and 64-bit programs?
On Oct 25, 2010, at 10:05 PM, suzuki toshiya wrote: Hi, Since 2.3.8? I'm really interested in, because I had committed many changes for 16-bit/64-bit platforms between 2.3.9 and 2.3.10. In your observation, 2.3.8 is ok but 2.3.9 is not ok? Or, 2.3.7 is ok but 2.3.8 is not ok? This problem didn't occur with 2.3.8, but it does occur with 2.4.2. Unfortunately, I haven't tried any versions in between. Yours, Tom 文林 Wenlin Institute, Inc.Software for Learning Chinese E-mail: wen...@wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
