Re: [ft-devel] "Inside the fastest font renderer in the world" - BUG FIX

[Nigel Tao]

On Mon, Aug 29, 2016 at 10:58 AM, Nigel Tao  wrote:
> The font-go patch to fix this (grep for "clamp") is at
> https://github.com/google/font-go/commit/568cda65618dfe210268a93e399db6c9ca409104

To clarify, this commit wasn't necessary for the "on-curve point at
the bottom right" out-of-bounds, as I had noticed and fixed that
earlier. What's new in that commit is letting you draw lines outside
the raster (and having it look reasonable) and I suspect would also
fix the "floating point rounding errors lead to a -1 index" problem
that Graham mentioned.

Prior to that commit, when drawing outside the raster (whether
explicitly or via a rounding error), you'd get a nonsense result
instead of a crashing result (Go programs automatically crash on an
array out-of-bounds), due to the explicit bounds checks I added before
that commit.

After that commit, as I said, you end up with something looking reasonable.

Speaking of floating point rounding, I also filed
https://github.com/google/font-rs/issues/13 "f32 -> u8 conversion
should multiply by 256-ε instead of by 255".

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] "Inside the fastest font renderer in the world" - BUG FIX

[Nigel Tao]

On Mon, Aug 22, 2016 at 12:06 AM, Graham Asher
 wrote:
> It was possible for the accumulation array to be written using an illegal
> index of -1.

Yeah, I also found an out-of-bounds panic (in my port to the Go
programming language, which is bounds-checked) when the glyph being
rendered has an on-curve point at the bottom right corner of the
rasterization buffer. You should be able to see this with the
capital-'I' glyph from a sans-serif font.

The font-rs bug is https://github.com/google/font-rs/issues/12

The font-go patch to fix this (grep for "clamp") is at
https://github.com/google/font-go/commit/568cda65618dfe210268a93e399db6c9ca409104

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] "Inside the fastest font renderer in the world" - BUG FIX

[Graham Asher]

I have found the bug causing the crash in my C version of the new 
floating-point rasterizer.


It was possible for the accumulation array to be written using an 
illegal index of -1. The cause was that when the DrawLine code steps 
through the y values - the raster lines - it increments the x value by 
dxdy, which is (dx / dy). That float value will inevitably sometimes be 
imprecise, causing the x value to become just less than 1. For example, 
if a line is drawn from (0.484375,0.34375) to (0,0.771965563), dxdy 
ought to be -1.131147585..., but is rounded to the float value 
-1.13114762. In the first and only raster line, dy is 0.428215563, so x 
= 0.48375 and xnext (the next value of x) is x + dy * dxdy = 
-2.98023224e-08 - NOT zero, as it should be, but a small way below zero: 
so when the array index x01 is set to the next integer below nextx it 
becomes -1.


Therefore the statement

float x0floor = (float)floor(x0);

becomes

float x0floor = x0 <= 0.0f ? 0.0f : (float)floor(x0);

with an explanatory comment. It goes without saying that changing from 
float to double would not fix the problem, only make it somewhat rarer.


I have uploaded the new version to 
http://www.cartotype.com/assets/downloads/raster_fp/ .


This was quite hard to debug because a write to the four bytes just 
before the start of a heap block does not cause an immediate crash. The 
crash happens when the block is deallocated. I added explicit array 
checking code, turned off optimisation in the release build of the 
CartoType demo (the debug build was too slow), ran it in the VS2015 
debugger and caught the bug on about the thirty-one-millionth array access.


Raph, you might like to check whether your Rust code has the same 
problem. I suspect that it does, because the lines (lines 69-70 in 
raster.rs)


let x0floor = x0.floor();
let x0i = x0floor as i32;

don't appear to prevent x0floor or x0i from being negative.

- Graham


On 19/08/2016 14:33, Graham Asher wrote:
Right now I think the supposed bug doesn't exist, but was caused by 
forcibly closing a debug session in Visual Studio 2015.


On 19/08/2016 14:02, Graham Asher wrote:
I've fixed the clipping and winding rule bugs, and it now works well 
with CartoType map rendering, and seems fast although I have not 
benchmarked it against the older renderer. However, one note of 
caution: I think there is still a bug somewhere, probably a write 
beyond the end of an array; no doubt that is my fault. I will try to 
reproduce and fix it.


I have uploaded the new version.

On 19/08/2016 11:16, Graham Asher wrote:

New version uploaded at

http://www.cartotype.com/assets/downloads/raster_fp/

which is going to be its home for now.

More news when I have done some more testing.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel






___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel