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

Re: [ft-devel] "Inside the fastest font renderer in the world" - first C version attached

[Raph Levien]

We have permission to adapt the code and integrate it into FreeType under
the FreeType license. I've followed up with Graham offline with a bit more
detail.

Hope that clears things up, and let me know if there are any remaining
concerns.

Thanks,

Raph

On Thu, Aug 18, 2016 at 10:28 PM, Raph Levien  wrote:

> I'm looking into the licensing question and will get back to you soon.
>
> Raph
>
> On Thu, Aug 18, 2016 at 10:16 PM, Werner LEMBERG  wrote:
>
>>
>> > I have successfully converted part of Raph Levien's code - that is,
>> > the floating-point rasterizer, not the TTF parser - into C, and it
>> > seems to work well, although I have run only a few small tests so
>> > far and have not yet benchmarked the speed.
>>
>> A big thank you, Graham!  Very much appreciated.  I don't know yet,
>> however, when I will find some time to work on it.
>>
>> In case you want to do further integration into FreeType, please post
>> your results here :-)
>>
>> > One point that I may have to address is that there are declarations
>> > after statements, which seems to be OK in C nowadays, but wasn't
>> > formerly, I know; but that can be fixed trivially.
>>
>> OK.
>>
>> > The code is attached. Naturally I have credited Raph and used the
>> > same license. There are documentation comments in the source.
>>
>> Regarding the license: Raph, would it be possible to add
>> dual-licensing with GPL2 to the C code, or to change the C code to the
>> two licenses that come with FreeType?  Reason is that Apache 2.0 is
>> not compatible with GPL2.
>>
>>
>> Werner
>>
>
>
___
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" - new version available

[Graham Asher]

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

Re: [ft-devel] "Inside the fastest font renderer in the world" - new version available

[Graham Asher]

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

Re: [ft-devel] "Inside the fastest font renderer in the world" - first C version attached

[Werner LEMBERG]

> I'll report back when I've tried it in CartoType.

Thanks.

> Note that my code runs fastest when formatted in Whitesmith's
> style ;-) Any attempt at reformatting will be stoutly resisted.

I fear to heavily disappoint you in the not too distant future :-)


Werner
___
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" - new version available

[Graham Asher]

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.


On 19/08/2016 09:27, Graham Asher wrote:
This isn't the final version; as always, after releasing a piece of 
code into the wild, one sees problems and omissions. Some notes:


1. My code does clipping, so that you can happily draw lines outside 
the raster. That isn't quite right yet - I need to make a simple change.


2. I am using a different winding rule from Raph. I will also fix 
that. Raph, can you comment on your winding-rule code? It takes the 
absolute value of the coverage then clamps it to 0...1 in your code; 
that seems to implement the non-zero winding rule.


3. It would be great to get Raph's comments on my cubic-spline code, 
built on the analogy of his quadratic code; and on the use of the 
magic constants 0.333 and 3.0 in determining the number of iterations 
when splitting a curve, and on the taking of a fourth root.


4. Raph's code uses 32-bit floating point numbers (float); it might be 
better to use 64-bit (double), because I believe that C always 
calculates to double-precision in any case, and so there is a 
conversion cost. I believe Raph uses float because floats are handled 
faster than doubles by hardware-accelerated SIMD code; but if not 
using SIMD, double may be better. There is also the raster working 
data size question. I use rasterization for large shapes in maps: a 
1000 x 1000 pixel display needs 4Mb of working data in this system, 
with floats, and 8Mb with doubles. Not really a problem nowadays, but 
much larger than the typical FreeType rasterizer's render pool.


I'll report back when I've tried it in CartoType.

Note that my code runs fastest when formatted in Whitesmith's style 
;-) Any attempt at reformatting will be stoutly resisted.


- Graham


On 19/08/2016 06:16, Werner LEMBERG wrote:

I have successfully converted part of Raph Levien's code - that is,
the floating-point rasterizer, not the TTF parser - into C, and it
seems to work well, although I have run only a few small tests so
far and have not yet benchmarked the speed.

A big thank you, Graham!  Very much appreciated.  I don't know yet,
however, when I will find some time to work on it.

In case you want to do further integration into FreeType, please post
your results here :-)


One point that I may have to address is that there are declarations
after statements, which seems to be OK in C nowadays, but wasn't
formerly, I know; but that can be fixed trivially.

OK.


The code is attached. Naturally I have credited Raph and used the
same license. There are documentation comments in the source.

Regarding the license: Raph, would it be possible to add
dual-licensing with GPL2 to the C code, or to change the C code to the
two licenses that come with FreeType?  Reason is that Apache 2.0 is
not compatible with GPL2.


 Werner

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




--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191


___
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

Re: [ft-devel] "Inside the fastest font renderer in the world" - first C version attached

[Raph Levien]

I'm looking into the licensing question and will get back to you soon.

Raph

On Thu, Aug 18, 2016 at 10:16 PM, Werner LEMBERG  wrote:

>
> > I have successfully converted part of Raph Levien's code - that is,
> > the floating-point rasterizer, not the TTF parser - into C, and it
> > seems to work well, although I have run only a few small tests so
> > far and have not yet benchmarked the speed.
>
> A big thank you, Graham!  Very much appreciated.  I don't know yet,
> however, when I will find some time to work on it.
>
> In case you want to do further integration into FreeType, please post
> your results here :-)
>
> > One point that I may have to address is that there are declarations
> > after statements, which seems to be OK in C nowadays, but wasn't
> > formerly, I know; but that can be fixed trivially.
>
> OK.
>
> > The code is attached. Naturally I have credited Raph and used the
> > same license. There are documentation comments in the source.
>
> Regarding the license: Raph, would it be possible to add
> dual-licensing with GPL2 to the C code, or to change the C code to the
> two licenses that come with FreeType?  Reason is that Apache 2.0 is
> not compatible with GPL2.
>
>
> Werner
>
___
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" - first C version attached

[Werner LEMBERG]

> I have successfully converted part of Raph Levien's code - that is,
> the floating-point rasterizer, not the TTF parser - into C, and it
> seems to work well, although I have run only a few small tests so
> far and have not yet benchmarked the speed.

A big thank you, Graham!  Very much appreciated.  I don't know yet,
however, when I will find some time to work on it.

In case you want to do further integration into FreeType, please post
your results here :-)

> One point that I may have to address is that there are declarations
> after statements, which seems to be OK in C nowadays, but wasn't
> formerly, I know; but that can be fixed trivially.

OK.

> The code is attached. Naturally I have credited Raph and used the
> same license. There are documentation comments in the source.

Regarding the license: Raph, would it be possible to add
dual-licensing with GPL2 to the C code, or to change the C code to the
two licenses that come with FreeType?  Reason is that Apache 2.0 is
not compatible with GPL2.


Werner

___
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" - conversion started

[Graham Asher]

Behdad,

It might be faster, but then again it might not be, depending on the 
value of n, the cost of the test for subdivision, and other things. I 
shall leave all of ftsmooth untouched; this will be an independent piece 
of software that may be connected to FreeType afterwards. However, I 
shall not be engaging in a general discussion about this, except for the 
odd question to Raph, but getting on with it, using my judgement as to 
how to proceed - committee programming is not for me. Anyone who wants 
to try other ways of converting what is a small piece of software can 
try their hand; as I said, there's no rocket science involved.


- Graham


On 12/08/2016 21:38, Behdad Esfahbod wrote:


Because it's faster to subdivide into n segments in a single loop.  
But yeah, that doesn't really matter here, I think you can leave that 
part of ftsmooth untouched.



On Aug 12, 2016 7:15 AM, "Graham Asher" > wrote:


Hi Werner,

yes, I e-mailed him yesterday, and asked a question about his code
too, but with no great hope of an early reply, knowing he's busy.
I asked him why his code to handle quadratic splines used a
division into a number of evenly spaced values for the t parameter
rather than recursive Casteljau splitting. The question was
triggered by seeing that there is a handler for quadratic splines
but not for cubics in his code (it was written for TrueType only).
I suspect the answer has to do with the use of floating-point
rather than integer arithmetic, but if there is no good reason I
will be tempted to (for now) use Casteljau splitting for cubic
splines, or for both types. I am almost certain that it will have
little impact on efficiency, or even improve it, but let's see.

- Graham


On 12/08/2016 06:45, Werner LEMBERG wrote:

Hello Graham,

I have started converting it to C++.  I will do that for
now because
C would adds an extra layer of difficulty and slow the
work down;
but don't worry, there's no rocket science, and it should
be easy to
produce a C version when I've done it.

great!  Please inform Raph also (in case you haven't done so);
I think
he is not on this list.

Wish me luck...

I do :-)


 Werner

___
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




--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
___
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" - conversion started

[Behdad Esfahbod]

Because it's faster to subdivide into n segments in a single loop.  But
yeah, that doesn't really matter here, I think you can leave that part of
ftsmooth untouched.

On Aug 12, 2016 7:15 AM, "Graham Asher"  wrote:

> Hi Werner,
>
> yes, I e-mailed him yesterday, and asked a question about his code too,
> but with no great hope of an early reply, knowing he's busy. I asked him
> why his code to handle quadratic splines used a division into a number of
> evenly spaced values for the t parameter rather than recursive Casteljau
> splitting. The question was triggered by seeing that there is a handler for
> quadratic splines but not for cubics in his code (it was written for
> TrueType only). I suspect the answer has to do with the use of
> floating-point rather than integer arithmetic, but if there is no good
> reason I will be tempted to (for now) use Casteljau splitting for cubic
> splines, or for both types. I am almost certain that it will have little
> impact on efficiency, or even improve it, but let's see.
>
> - Graham
>
>
> On 12/08/2016 06:45, Werner LEMBERG wrote:
>
>> Hello Graham,
>>
>> I have started converting it to C++.  I will do that for now because
>>> C would adds an extra layer of difficulty and slow the work down;
>>> but don't worry, there's no rocket science, and it should be easy to
>>> produce a C version when I've done it.
>>>
>> great!  Please inform Raph also (in case you haven't done so); I think
>> he is not on this list.
>>
>> Wish me luck...
>>>
>> I do :-)
>>
>>
>>  Werner
>>
>> ___
>> 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
>
___
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" - conversion started

[Graham Asher]

Hi Werner,

yes, I e-mailed him yesterday, and asked a question about his code too, 
but with no great hope of an early reply, knowing he's busy. I asked him 
why his code to handle quadratic splines used a division into a number 
of evenly spaced values for the t parameter rather than recursive 
Casteljau splitting. The question was triggered by seeing that there is 
a handler for quadratic splines but not for cubics in his code (it was 
written for TrueType only). I suspect the answer has to do with the use 
of floating-point rather than integer arithmetic, but if there is no 
good reason I will be tempted to (for now) use Casteljau splitting for 
cubic splines, or for both types. I am almost certain that it will have 
little impact on efficiency, or even improve it, but let's see.


- Graham


On 12/08/2016 06:45, Werner LEMBERG wrote:

Hello Graham,


I have started converting it to C++.  I will do that for now because
C would adds an extra layer of difficulty and slow the work down;
but don't worry, there's no rocket science, and it should be easy to
produce a C version when I've done it.

great!  Please inform Raph also (in case you haven't done so); I think
he is not on this list.


Wish me luck...

I do :-)


 Werner

___
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

Re: [ft-devel] "Inside the fastest font renderer in the world" - conversion started

[Werner LEMBERG]

Hello Graham,

> I have started converting it to C++.  I will do that for now because
> C would adds an extra layer of difficulty and slow the work down;
> but don't worry, there's no rocket science, and it should be easy to
> produce a C version when I've done it.

great!  Please inform Raph also (in case you haven't done so); I think
he is not on this list.

> Wish me luck...

I do :-)


Werner

___
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"

[Alexei Podtelezhnikov]

There is an API to use whatever rasterizer you please  with the rest of the 
Freetype 
https://www.freetype.org/freetype2/docs/reference/ft2-raster.html

> On Aug 5, 2016, at 03:42, Graham Asher  wrote:
> 
> I might take a look at it, but no guarantees about my availability. I would 
> convert it into C++, not C; C++ is a better fit, and there is really no point 
> in using C these days. I would provide a C interface for compatibility.
> 
> - Graham
> 
> 
>> On 04/08/2016 20:42, Werner LEMBERG wrote:
>>> A first step towards making this new renderer generally useful would
>>> be to convert it or compile it (using the Crust compiler) to C.
>> Is there a volunteer for this?  Raph is quite busy, he told me...
>> 
>> 
>> Werner
> 
> -- 
> Graham Asher
> founder and CTO
> CartoType Ltd
> graham.as...@cartotype.com
> +44 (0) 7718 895191
___
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"

[Graham Asher]

I'd forgotten about that! I was the other person.

On 05/08/2016 09:21, Ken Sharp wrote:
Personally, as one of the two people who did a load of work to get 
FreeType integrated into Ghostscript


--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
___
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"

[Ken Sharp]

At 09:09 05/08/2016 +0100, Graham Asher wrote:

I see your point, but I think that adding obfuscation (the extra 
complexity introduced by using C) to the code to support a tiny and 
vanishing minority of systems without C++ is not worth the bother; such 
systems would very probably not be able to run FreeType in any case 
because of lack of support for 32-bit integers; and I doubt very much 
whether they would have any need to rasterize glyphs.


Speaking for Ghostscript, this is not the case. We are required to support 
a number of embedded operating systems, many of which are of some degree of 
legacy and which have limited (if any) support for C++.


These platforms drive printers, which very much do have a need to render 
glyphs :-) Please don't assume that all glyph rendering is for screen display!


I no longer have responsibility for FreeType in Ghostscript, but if FT were 
to move to requiring C++ I think we would have to fork it (as we did once 
before) in order to maintain a pure C build. Personally, as one of the two 
people who did a load of work to get FreeType integrated into Ghostscript 
in place of the (old) fork that was being used, I'd be very disappointed to 
have to go back to using a fork.



Ken


___
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"

[Graham Asher]

Werner,

I see your point, but I think that adding obfuscation (the extra 
complexity introduced by using C) to the code to support a tiny and 
vanishing minority of systems without C++ is not worth the bother; such 
systems would very probably not be able to run FreeType in any case 
because of lack of support for 32-bit integers; and I doubt very much 
whether they would have any need to rasterize glyphs.


There's an interesting discussion here 
(http://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems) 
which gives both sides of the issue, but which contains many errors and 
irrelevancies... however, I respect your point of view and won't tread a 
well-worn path again.


Best regards,

Graham


On 05/08/2016 09:00, Werner LEMBERG wrote:

I might take a look at it, but no guarantees about my availability.

Thanks for the offer anyway :-)


I would convert it into C++, not C; C++ is a better fit, and there
is really no point in using C these days.

I disagree.  As far as I know, there are still embedded systems that
don't have a C++ compiler (and probably never will).  Given that
everything in FreeType is C, it would be a severe complication if just
a single file becomes C++.  In other words, I would have to convert
your C++ code in C, which means double work...

As an alternative, there is

   https://github.com/uwplse/crust

a Rust-to-C compiler – has anyone tried this?  I don't know whether it
produces code which runs as fast as the Rust equivalent.  If this
works reliably, I could imagine to have both a Rust source file and
its translation in the FreeType git repository.  Unfortunately,
`crust' needs a huuuge set of preliminaries...


 Werner


--
Graham Asher
founder and CTO
CartoType Ltd
graham.as...@cartotype.com
+44 (0) 7718 895191
___
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"

[Werner LEMBERG]

> I might take a look at it, but no guarantees about my availability.

Thanks for the offer anyway :-)

> I would convert it into C++, not C; C++ is a better fit, and there
> is really no point in using C these days.

I disagree.  As far as I know, there are still embedded systems that
don't have a C++ compiler (and probably never will).  Given that
everything in FreeType is C, it would be a severe complication if just
a single file becomes C++.  In other words, I would have to convert
your C++ code in C, which means double work...

As an alternative, there is

  https://github.com/uwplse/crust

a Rust-to-C compiler – has anyone tried this?  I don't know whether it
produces code which runs as fast as the Rust equivalent.  If this
works reliably, I could imagine to have both a Rust source file and
its translation in the FreeType git repository.  Unfortunately,
`crust' needs a huuuge set of preliminaries...


Werner
___
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"

[Nikolaus Waxweiler]

Conceptually, are we into parallelizing Freetype rendering engine? As
I alluded earlier this can be happily delegated to text layout
engines.


Not sure where that sentiment is coming from. Raph's concept is about 
increasing the efficiency of the (parsing and) rendering process, how is 
that something outside the scope of FreeType? The article talks about 
using less space-efficient data structures so that SIMD instructions can 
burn through the data more quickly (and maybe in parallel because no 
single date depends on another) and with next to no branch 
misprediction. You can still parallelize stuff inside text layout 
engines for even more efficiency.


___
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"

[Alexei Podtelezhnikov]

On Thu, Aug 4, 2016 at 4:23 PM, Behdad Esfahbod  wrote:

>> Conceptually, are we into parallelizing Freetype rendering engine? As
>> I alluded earlier this can be happily delegated to text layout
>> engines. Hence we used to care about thread safety in Freetype, while
>> the text layout engine is busy processing 8 letters at once. Raph uses
>> at least 8-core processor. I would be interested to see how his
>> renderer performs on a single core, without parallel tricks.
>
> You are seriously misunderstanding what font-rs is doing.  It's using
> SIMD instructions [0].  That's still one core.  And, he's also showing
> 6x speedup without SIMD.  Really, it's just plain honest tight piece
> of code.  No magic involved.

Alright. Last time somebody has done actual profiling [1], it was
arithmetic of calculating coverages that took all the time,
specifically divisions. Is that the problem solved by font-rs? You do
not even need 'g' to stress-test rendering: a slanted line or a '/'
would do. I do not understand how 6x is even possible. I wish the
paper analyzed weaknesses of Freetype in more details.

[1] http://lists.nongnu.org/archive/html/freetype-devel/2015-10/msg00027.html

___
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"

[Behdad Esfahbod]

On Thu, Aug 4, 2016 at 1:19 PM, Alexei Podtelezhnikov
 wrote:
> On Thu, Aug 4, 2016 at 3:42 PM, Werner LEMBERG  wrote:
>>
>>> A first step towards making this new renderer generally useful would
>>> be to convert it or compile it (using the Crust compiler) to C.
>>
>> Is there a volunteer for this?  Raph is quite busy, he told me...
>
> Conceptually, are we into parallelizing Freetype rendering engine? As
> I alluded earlier this can be happily delegated to text layout
> engines. Hence we used to care about thread safety in Freetype, while
> the text layout engine is busy processing 8 letters at once. Raph uses
> at least 8-core processor. I would be interested to see how his
> renderer performs on a single core, without parallel tricks.

You are seriously misunderstanding what font-rs is doing.  It's using
SIMD instructions [0].  That's still one core.  And, he's also showing
6x speedup without SIMD.  Really, it's just plain honest tight piece
of code.  No magic involved.

[0] https://en.wikipedia.org/wiki/SIMD

-- 
behdad
http://behdad.org/rr

___
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"

[Alexei Podtelezhnikov]

On Thu, Aug 4, 2016 at 3:42 PM, Werner LEMBERG  wrote:
>
>> A first step towards making this new renderer generally useful would
>> be to convert it or compile it (using the Crust compiler) to C.
>
> Is there a volunteer for this?  Raph is quite busy, he told me...

Conceptually, are we into parallelizing Freetype rendering engine? As
I alluded earlier this can be happily delegated to text layout
engines. Hence we used to care about thread safety in Freetype, while
the text layout engine is busy processing 8 letters at once. Raph uses
at least 8-core processor. I would be interested to see how his
renderer performs on a single core, without parallel tricks.

Thank you,
Alexei

___
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"

[Werner LEMBERG]

> - the main strength of FreeType is not speed - though it is
> amazingly fast.  the main strength is that it has had random crap
> thrown at it for 20+ years.  Doing rendering on perfectly valid and
> good fonts is fine, so Raph's answer definitely earns its place, in
> the environment where Google concentrates on Androids, etc - make it
> very fast for *selected good* fonts.  Random crap fonts? Don't know
> how adding error recovery etc slows down the new solution yet.

This seems to be a misunderstanding.  Raph's speedy stuff is not about
parsing TrueType fonts but *rendering* outlines into bitmaps.  The
TrueType parser he has written in addition to the rasterizer was just
a proof of concept; it doesn't bring very much speed advantage.

> - the exotic language Rust. Finding people to maintain/contribute
> code written in a niche language (and quite an unusual one as that)
> is hard.  It may bit-rot if the origin owner loses interests.

As mentioned in another mail, Raph searches a volunteer for converting
it to C.  If you look at his code repository, the similarity to C is
quite high.


Werner

___
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"

[Werner LEMBERG]

> A first step towards making this new renderer generally useful would
> be to convert it or compile it (using the Crust compiler) to C.

Is there a volunteer for this?  Raph is quite busy, he told me...


Werner

___
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" (Re: Freetype-devel Digest, Vol 139, Issue 3)

[Patrick Lam]

In case anyone is curious about Rust, I just looked into it in some
detail recently. You can program it imperatively, although it also
supports most features of functional languages. There will be less
culture shock coming from C to Rust than from C to O'Caml for sure.

As I alluded to earlier, Rust does better at memory management than C,
and the compiler enforces the memory management for you without
garbage collection and without refcounting. But everything has to have
a single owner. (This can cause some learning curve). The compiler
knows when things are no longer referenced and then deallocates them.

pat


On Thu, Aug 4, 2016 at 8:24 PM, Hin-Tak Leung
 wrote:
> I saw the post about it earlier on typedrawers. If it wasn't because of the 
> poster - Raph Levien - I'd just laugh it off. I'd usually be skeptical of 
> such a claim - because, in the end of the day, everything is machine 
> instructions, right? Shouldn't make any difference what language something is 
> written in, if your compiler is good enough. I trust Raph made a valid claim 
> though. However:
>
> - the main strength of FreeType is not speed - though it is amazingly fast. 
> the main strength is that it has had random crap thrown at it for 20+ years. 
> Doing rendering on perfectly valid and good fonts is fine, so Raph's answer 
> definitely earns its place, in the environment where Google concentrates on 
> Androids, etc - make it very fast for *selected good* fonts. Random crap 
> fonts? Don't know how adding error recovery etc slows down the new solution 
> yet.
>
> - the exotic language Rust. Finding people to maintain/contribute code 
> written in a niche language (and quite an unusual one as that) is hard. It 
> may bit-rot if the origin owner loses interests.
>
> It is hard enough to find people to contribute to the font validator, which 
> is in C#, rather common in windows land; and C# is close enough to both Java 
> and C, etc. Rust I heard is similar to Objective Caml, which is in turn 
> similar to haskell... (I heard!).
>
> ___
> 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