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 [.] 0x00000000001541c4 6.29% lt-ftbench libc.so.6 [.] 0x00000000001541ce 1.25% lt-ftbench libc.so.6 [.] 0x00000000001541d3 1.22% lt-ftbench libc.so.6 [.] 0x00000000001541c9 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 <apodt...@gmail.com> Sent: Friday, September 16, 2022 8:04 AM To: Anurag Thakur <anurag105cse...@bpitindia.edu.in> 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
