Re: [GSoC] Status of font-rs port
Hello Werner, I have converted the rasterizer to use fixed point, will post a more elaborate status report once I get SIMD working with fixed point, but here are the highlights: 1. Fixed point calculation is notably faster. 2. I have analysed fontdue, and it doesn't seem to have any significant difference in the rasterizer algorithm, just some minor improvements which I am in the process of porting over. 3. Added comments and cleaned up the code a bit. More documentation work in progress. 4. I am also testing the renderer on a variety of fonts and have found some issues, (specifically when the outlines overflow the glyph width). Will post more testing details and perf numbers in a report soon. Regards Anurag From: Werner LEMBERG Sent: Tuesday, 11 October, 2022, 11:17 AM To: Anurag Thakur Cc: apodt...@gmail.com ; freetype-devel@nongnu.org Subject: Re: [GSoC] Status of font-rs port Hello Anurag, what's the current state of your project? Please tell us what's going on :-) Werner
Re: [GSoC] Status of font-rs port
Hello Anurag, what's the current state of your project? Please tell us what's going on :-) Werner
RE: [GSoC] Status of font-rs port
> Do you mind continuing this discussion as an issue on GitLab? Created issue https://gitlab.freedesktop.org/freetype/freetype/-/issues/1184 for continuing discussion From: Alexei Podtelezhnikov Sent: Friday, September 16, 2022 9:59 PM To: Anurag Thakur Cc: freetype-devel@nongnu.org Subject: Re: [GSoC] Status of font-rs port Anurag > Can also look at some more challenging fonts with very fine curves, eg, > Windows' KUNSTLER.TTF I tested it, and the rasterizer output is almost identical. Curiously, for this font, the dense rasterizer is faster even till 200-300 ppem font size This is definitely because smooth is constrained by memory and has to restart (see longjmp) with narrower bands to handle the job. It looks like one restart for each glyph approximately. Relevant files attached. Do you mind continuing this discussion as an issue on GitLab? A
Re: [GSoC] Status of font-rs port
Anurag > > Can also look at some more challenging fonts with very fine curves, eg, > > Windows' KUNSTLER.TTF > > I tested it, and the rasterizer output is almost identical. > > Curiously, for this font, the dense rasterizer is faster even till 200-300 > ppem font size This is definitely because smooth is constrained by memory and has to restart (see longjmp) with narrower bands to handle the job. It looks like one restart for each glyph approximately. > Relevant files attached. Do you mind continuing this discussion as an issue on GitLab? A
Re: [GSoC] Status of font-rs port
Anurag, > 1 and 2 have been fixed, but monochrome output still crashes ftgrid for the > dense rasterizer Smooth returns Cannot_Render_Glyph for mono, thus passing the job to b/w raster. Dense should do the same. A.
Re: [GSoC] Status of font-rs port
> 1 and 2 have been fixed, but monochrome output still crashes ftgrid > for the dense rasterizer A good start would be a backtrace... Werner
RE: [GSoC] Status of font-rs port
Thanks for the quick fix! 1 and 2 have been fixed, but monochrome output still crashes ftgrid for the dense rasterizer I’ll investigate it and report Regards Anurag From: Alexei Podtelezhnikov Sent: Friday, September 16, 2022 9:16 AM To: Anurag Thakur Cc: freetype-devel@nongnu.org Subject: Re: [GSoC] Status of font-rs port On Thu, Sep 15, 2022 at 5:53 PM Anurag Thakur mailto:anurag105cse...@bpitindia.edu.in>> wrote: List of bugs I have encountered: 1. Ftgrid produces weird output and crashes at large sizes(~170ppem) 2. The inverted bitmap pitch causes rendering differences (can be seen in the “Q” letter of the ftview output) 3. Ftgrid crashes when selecting monochrome output Should be fixed by a005039b. Thanks for the report.
Re: [GSoC] Status of font-rs port
> Also, if there is some way of viewing the libc function name instead of > address, that would be helpful. I am sure these are malloc, free, memset, memcpy, etc. As the size increases they contribute more and more. Still, dense_raster_render must be spending some time just walking around the huge matrix. If you press Enter and Annotate, you will see the hottest lines.
RE: [GSoC] Status of font-rs port
Hello Alexei, > Can you confirm that straight line drawing still takes most of the time with > the dense rastrerizer? Running perf on ftbench reports: 10ppem: 22.20% lt-ftbench libfreetype.so.6.18.3 [.] dense_render_line 15.37% lt-ftbench libfreetype.so.6.18.3 [.] dense_render_quadratic 6.01% lt-ftbench libfreetype.so.6.18.3 [.] TT_Load_Simple_Glyph 5.76% lt-ftbench libfreetype.so.6.18.3 [.] FT_Outline_Get_CBox 3.79% lt-ftbench libfreetype.so.6.18.3 [.] load_truetype_glyph 3.22% ld libbfd-2.39.so [.] bfd_link_hash_traverse 2.46% lt-ftbench libfreetype.so.6.18.3 [.] FT_Outline_Decompose 1.23% lt-ftbench libfreetype.so.6.18.3 [.] dense_raster_render 100ppem: 48.12% lt-ftbench libfreetype.so.6.18.3 [.] dense_render_line 18.94% lt-ftbench libfreetype.so.6.18.3 [.] dense_raster_render 9.13% lt-ftbench libfreetype.so.6.18.3 [.] dense_render_quadratic 2.33% lt-ftbench libfreetype.so.6.18.3 [.] TT_Load_Simple_Glyph 2.11% lt-ftbench libfreetype.so.6.18.3 [.] FT_Outline_Get_CBox 1.75% lt-ftbench libm.so.6 [.] fminf32x 1.40% lt-ftbench libfreetype.so.6.18.3 [.] load_truetype_glyph 1.36% lt-ftbench libm.so.6 [.] fmaxf32x 1.10% lt-ftbench libfreetype.so.6.18.3 [.] FT_Outline_Decompose 1000ppem: 70.29% lt-ftbench libfreetype.so.6.18.3 [.] dense_raster_render 10.60% lt-ftbench libfreetype.so.6.18.3 [.] dense_render_line 6.88% lt-ftbench libc.so.6 [.] 0x001541c4 6.29% lt-ftbench libc.so.6 [.] 0x001541ce 1.25% lt-ftbench libc.so.6 [.] 0x001541d3 1.22% lt-ftbench libc.so.6 [.] 0x001541c9 0.68% lt-ftbench libfreetype.so.6.18.3 [.] dense_render_quadratic 0.38% lt-ftbench libm.so.6 [.] fminf32x 0.32% lt-ftbench libm.so.6 [.] fmaxf32x I believe something changes at around 200ppem that causes the rendering time to increase dramatically. Will investigate and report. Also, if there is some way of viewing the libc function name instead of address, that would be helpful. Regards Anurag From: Alexei Podtelezhnikov Sent: Friday, September 16, 2022 8:04 AM To: Anurag Thakur Cc: freetype-devel@nongnu.org Subject: Re: [GSoC] Status of font-rs port Hi Anurag, The rasterizer code (including SIMD) has been integrated into the FreeType and seems to be working fine, Comparison images: dense and smooth renderer (outlines and dots disabled) This is a really nice progress indeed. The images look almost identical. Can also look at some more challenging fonts with very fine curves, eg, Windows' KUNSTLER.TTF. We need to make sure that both rasterizers are tuned to similar quality. The performance is comparable (sometimes better) to the smooth renderer for small font sizes, however it is several times slower for larger sizes This is really quite stunning. I look forward to further progress. Can you confirm that straight line drawing still takes most of the time with the dense rastrerizer? I am thinking of working on the “Direct rendering mode” next. Any pointers regarding that would be appreciated. I am not sure about this one. The whole point of direct mode is to leave the canvas allocation to the client. The dense rasterizer defeats this purpose. And just for reference List of bugs I have encountered: 1. Ftgrid produces weird output and crashes at large sizes(~170ppem) 2. The inverted bitmap pitch causes rendering differences (can be seen in the “Q” letter of the ftview output) Hmm. Is this only when Q is on the last row? That would be an ftview bug then. I do not see any problems with parentheses? Is this 2.12.1 demos? 3. Ftgrid crashes when selecting monochrome output Do you think this is also a pitch sign bug? 4. [TODO] lcd rendering needs to be implemented This is either three interlaced bitmaps after shifts, or 3x resolution with filtering. You should be able to copy this from smooth. Best, Alexei
Re: [GSoC] Status of font-rs port
On Thu, Sep 15, 2022 at 5:53 PM Anurag Thakur < anurag105cse...@bpitindia.edu.in> wrote: > List of bugs I have encountered: > 1. Ftgrid produces weird output and crashes at large sizes(~170ppem) > > 2. The inverted bitmap pitch causes rendering differences (can be seen in > the “Q” letter of the ftview output) > > 3. Ftgrid crashes when selecting monochrome output > Should be fixed by *a005039b.* Thanks for the report.
Re: [GSoC] Status of font-rs port
Hi Anurag, The rasterizer code (including SIMD) has been integrated into the FreeType > and seems to be working fine, > > Comparison images: dense and smooth renderer (outlines and dots disabled) > This is a really nice progress indeed. The images look almost identical. Can also look at some more challenging fonts with very fine curves, eg, Windows' KUNSTLER.TTF. We need to make sure that both rasterizers are tuned to similar quality. > The performance is comparable (sometimes better) to the smooth renderer > for small font sizes, however it is several times slower for larger sizes > This is really quite stunning. I look forward to further progress. Can you confirm that straight line drawing still takes most of the time with the dense rastrerizer? > I am thinking of working on the “Direct rendering mode” next. Any pointers > regarding that would be appreciated. > I am not sure about this one. The whole point of direct mode is to leave the canvas allocation to the client. The dense rasterizer defeats this purpose. > And just for reference > > List of bugs I have encountered: > 1. Ftgrid produces weird output and crashes at large sizes(~170ppem) > > 2. The inverted bitmap pitch causes rendering differences (can be seen in > the “Q” letter of the ftview output) > Hmm. Is this only when Q is on the last row? That would be an ftview bug then. I do not see any problems with parentheses? Is this 2.12.1 demos? 3. Ftgrid crashes when selecting monochrome output Do you think this is also a pitch sign bug? 4. [TODO] lcd rendering needs to be implemented This is either three interlaced bitmaps after shifts, or 3x resolution with filtering. You should be able to copy this from smooth. Best, Alexei
