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
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
[ft-devel] [patch] on the subject of better splines
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