Re: [ft-devel] [patch] on the subject of better splines
Alexi, I think it's a good idea if you can benchmark the code to see if the extra arithmetic results in any speed improvement. I suspect it might slow things down slightly for ordinary glyphs which always fit in a single band, but there's a chance it might help at high resolutions where more than one band is needed. Also, at first glance your code looks as if it might be subject to integer overflow or division by zero. The patch that's just been checked in result from work by David Bevan and myself does in fact make some improvements to gray_render_conic, though it doesn't address the point you are making. Best regards, Graham On 02/10/2010 03:57, Алексей Подтележников wrote: Hello, While you guys are on the subject of better splines. I propose to fix grey_render_conic too. I think that interpreting the control point as a corner is a simplistic overestimation. A little algebra gives the exact boundary position. Nothing breaks at the firsts glance in my testing. Whether this speeds things up, I do not know how to measure. Lastly. the equation below assumes that conic really means quadratic, in agreement with the logic of grey_split_conic. Comments? Alexi --- a/src/smooth/ftgrays.c 2010-07-12 15:09:25.0 -0400 +++ b/src/smooth/ftgrays.c 2010-10-01 21:58:05.182637518 -0400 @@ -936,16 +936,18 @@ TPos min, max, y; +/* set the boundaries based on the endpoints */ min = max = arc[0].y; -y = arc[1].y; -if ( y min ) min = y; -if ( y max ) max = y; - y = arc[2].y; if ( y min ) min = y; if ( y max ) max = y; +/* amend the boundaries based on the control point */ +y = arc[1].y; +if ( y min ) min = (min * max - y * y) / (min + max - 2 * y); +if ( y max ) max = (min * max - y * y) / (min + max - 2 * y); + if ( TRUNC( min )= ras.max_ey || TRUNC( max ) ras.min_ey ) goto Draw; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FreeType 2.4.3 has been released
FreeType 2.4.3 has been released. All users should upgrade. It is available from http://savannah.nongnu.org/download/freetype/ or https://sourceforge.net/projects/freetype/files/ The latter site also holds older versions of the FreeType library. See below for the relevant snippet from the CHANGES file. Enjoy! Werner -- FreeType 2 is a software font engine that is designed to be small, efficient, highly customizable, and portable while capable of producing high-quality output (glyph images) of most vector and bitmap font formats. Note that FreeType 2 is a font service and doesn't provide APIs to perform higher-level features, like text layout or graphics processing (e.g., colored text rendering, `hollowing', etc.). However, it greatly simplifies these tasks by providing a simple, easy to use, and uniform interface to access the content of font files. FreeType 2 is released under two open-source licenses: our own BSD-like FreeType License and the GPL. It can thus be used by any kind of projects, be they proprietary or not. -- CHANGES BETWEEN 2.4.2 and 2.4.3 I. IMPORTANT BUG FIXES - Fix rendering of certain cubic, S-shaped arcs. This regression has been introduced in version 2.4.0. II. MISCELLANEOUS - To fix the above mentioned rendering issue, a new spline flattening algorithm has been introduced which speeds up both conic and cubic arcs. - Handling of broken fonts has been further improved. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] on the subject of better splines
Graham, 2010/10/3 Graham Asher graham.as...@btinternet.com: there's a chance it might help at high resolutions where more than one band is needed. True, I have nothing to show for it besides correctness. The speed up is barely visible. Is 72 enough to cross bands? BEFORE: ftbench -b c -s 72 /mnt/windows/WINDOWS/Fonts/times.ttf Render: 38.585 us/op Render: 34.794 us/op Render: 34.773 us/op Render: 35.419 us/op Render: 34.757 us/op Render: 35.333 us/op Render: 35.395 us/op Render: 35.239 us/op Render: 34.947 us/op AFTER: ftbench -b c -s 72 /mnt/windows/WINDOWS/Fonts/times.ttf Render: 35.092 us/op Render: 34.761 us/op Render: 34.964 us/op Render: 34.680 us/op Render: 35.490 us/op Render: 34.852 us/op Render: 34.651 us/op Render: 34.678 us/op Render: 34.679 us/op Also, at first glance your code looks as if it might be subject to integer overflow or division by zero. The division by zero is out of question, not under the imposed condition. The patch below makes the overflow much less likely. The fact that this band check matters so little makes me think that it is out of place there, even though it is very cheap. --- a/src/smooth/ftgrays.c 2010-10-03 14:16:22.726223420 -0400 +++ b/src/smooth/ftgrays.c 2010-10-03 18:07:11.189192598 -0400 @@ -926,16 +926,18 @@ TPos min, max, y; +/* consider the endpoints first */ min = max = arc[0].y; -y = arc[1].y; -if ( y min ) min = y; -if ( y max ) max = y; - y = arc[2].y; if ( y min ) min = y; if ( y max ) max = y; +/* amend the boundaries based on the control point */ +y = arc[1].y; +if ( y min ) min += (y - min) * (y - min) / (2 * y - max - min); +if ( y max ) max += (y - max) * (y - max) / (2 * y - max - min); + if ( TRUNC( min ) = ras.max_ey || TRUNC( max ) ras.min_ey ) goto Draw; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
