Re: ftbench update: make integrated
Here is my new bunch of remarks. In total, we are getting nearer to meaningful results :-) * The build process seems to be ok now, very good! * After doing `make baseline` (and `make benchmark`) I see as the last line ``` Processing 100%...\nBaseline created. ``` This `\n' looks strange. * It would be nice if `make benchmark` shows as the last line something like ``` Benchmark results created in file `/foo/bar/benchmark.html`. ``` * Looking at `benchmark.html`, I'm quite happy now with the layout, thanks! However, running baseline and benchmark tests for the same commit on my computer I'm still 'greeted' in the very first test line with ``` Load 47500 0.167 0.228 -36.5 ``` 36.5% run difference is bd. AFAICS, you haven't yet worked on omitting 'warmup' iterations, right? * In `benchmark.html`, I see ``` *Smaller values mean faster operation ``` please insert a space after '*'. Additionally, you should mark the columns that are affected by this comment with '*', too, so that the reader knows what you are referring to. Werner
Re: Progress update on adjustment database
> > Just take the extrema of *all* points – for fonts this should be > > good enough, because it is standard to have points at the curve > > extrema, thus making the bounding box of the curve identical to > > the bounding box of the points (both on and off points). > > Ok, thanks. This is exactly what I needed. I was already trying > this, but I thought it was wrong because of off points. For your information, you might also look at FreeType's function `FT_Glyph_Get_CBox`, which handles the generic case. > What I mean is: my code allows the adjustment for i to be applied to > glyphs with more than 2 contours to also adjust accented o and a, so > the rules you suggested would reject around half of the characters > that are currently being adjusted this way. I think your rules can > still be enforced by treating the contour to be moved as "A" and all > other contours collectively as "B". Yeah, I was especially referring to glyph 'i', since here the problem is most visible. >> [...] I ask you to have this in mind to find a solution that can be >> easily extended to cover this situation, too (for example, by using >> an extendable structure instead of a plain variable). > > In this case, do you mean that instead of making a codepoint a key > for the database directly, I should wrap it in a struct so that > other kind of keys can be added? Something like this, yes. Just try to be generic, and think of possible extensions. Werner
Re: Progress update on adjustment database
> What exactly do you mean with 'find'? The algorithm? Just take the extrema of *all* points – for fonts this should be good enough, because it is standard to have points at the curve extrema, thus making the bounding box of the curve identical to the bounding box of the points (both on and off points). Ok, thanks. This is exactly what I needed. I was already trying this, but I thought it was wrong because of off points. > What exact rule are you referring to? My rule #3 > doesn't seem to fit what you are talking about... Sorry for being unclear. What I mean is: my code allows the adjustment for i to be applied to glyphs with more than 2 contours to also adjust accented o and a, so the rules you suggested would reject around half of the characters that are currently being adjusted this way. I think your rules can still be enforced by treating the contour to be moved as "A" and all other contours collectively as "B". > No, I'm not, but I ask you to have this in mind to find a solution > that can be easily extended to cover this situation, too (for example, > by using an extendable structure instead of a plain variable). In this case, do you mean that instead of making a codepoint a key for the database directly, I should wrap it in a struct so that other kind of keys can be added? That sounds like a good solution On Sun, Jul 30, 2023 at 4:14 AM Werner LEMBERG wrote: > > Hello Craig, > > > again sorry for the late reply. > > > During this time, I realized that knowing the bounding box of the > > tilde contour would help a lot. In fact, the logic for the other > > vertical separation adjustments assumes that it can get the bounding > > box by taking the minimum/maximum coordinates of all the points, but > > this doesn't work because of off-points, which I didn't consider at > > the time. How do you find this bounding box? > > What exactly do you mean with 'find'? The algorithm? Just take the > extrema of *all* points – for fonts this should be good enough, > because it is standard to have points at the curve extrema, thus > making the bounding box of the curve identical to the bounding box of > the points (both on and off points). > > > I should note that, in your example, check #3 is too restrictive. > > The logic allows for the bottom shape that needs to be separated to > > be made up of any number of contours, which allows it to work for > > characters with more complex shapes. > > What exact rule are you referring to? My rule #3 was > > (3) All points of A are lower than all points of B (or vice versa). > > which doesn't seem to fit what you are talking about... > > > I want to clarify: are you adding glyph names in the database as a > > requirement for the project? > > No, I'm not, but I ask you to have this in mind to find a solution > that can be easily extended to cover this situation, too (for example, > by using an extendable structure instead of a plain variable). > > > Werner >
CFF loading overhead in tracing
Hi, In benchmarking FreeType face loading, I noticed that the following two loops take considerable time when loading CFF1 face: --- a/src/cff/cffobjs.c +++ b/src/cff/cffobjs.c @@ -695,8 +695,8 @@ FT_TRACE4(( " %5d ", idx + 390 )); - for ( l = 0; l < s1len; l++ ) -FT_TRACE4(( "%c", s1[l] )); + //for ( l = 0; l < s1len; l++ ) +//FT_TRACE4(( "%c", s1[l] )); FT_TRACE4(( "\n" )); } @@ -710,8 +710,8 @@ FT_TRACE4(( " %5d ", cff->num_strings + 390 )); - for ( l = 0; l < s1len; l++ ) -FT_TRACE4(( "%c", s1[l] )); + //for ( l = 0; l < s1len; l++ ) +//FT_TRACE4(( "%c", s1[l] )); FT_TRACE4(( "\n" )); } } I don't have tracing enabled, but the compiler doesn't seem to have wiped away the loop. I'm not sure why. At any rate, I wonder if these can be guarded by FT_DEBUG_TRACE or some other way to remove the overhead? behdad http://behdad.org/
Re: CFF loading overhead in tracing
Humm. I cannot reproduce this anymore. Will report if that changes. behdad http://behdad.org/ On Sun, Jul 30, 2023 at 12:41 PM Behdad Esfahbod wrote: > Hi, > > In benchmarking FreeType face loading, I noticed that the following two > loops take considerable time when loading CFF1 face: > > > --- a/src/cff/cffobjs.c > +++ b/src/cff/cffobjs.c > @@ -695,8 +695,8 @@ > > >FT_TRACE4(( " %5d ", idx + 390 )); > - for ( l = 0; l < s1len; l++ ) > -FT_TRACE4(( "%c", s1[l] )); > + //for ( l = 0; l < s1len; l++ ) > +//FT_TRACE4(( "%c", s1[l] )); >FT_TRACE4(( "\n" )); > } > > @@ -710,8 +710,8 @@ > > >FT_TRACE4(( " %5d ", cff->num_strings + 390 )); > - for ( l = 0; l < s1len; l++ ) > -FT_TRACE4(( "%c", s1[l] )); > + //for ( l = 0; l < s1len; l++ ) > +//FT_TRACE4(( "%c", s1[l] )); >FT_TRACE4(( "\n" )); > } >} > > > I don't have tracing enabled, but the compiler doesn't seem to have wiped > away the loop. I'm not sure why. At any rate, I wonder if these can be > guarded by FT_DEBUG_TRACE or some other way to remove the overhead? > > > behdad > http://behdad.org/ >
Re: Progress update on adjustment database
Hello Craig, again sorry for the late reply. > During this time, I realized that knowing the bounding box of the > tilde contour would help a lot. In fact, the logic for the other > vertical separation adjustments assumes that it can get the bounding > box by taking the minimum/maximum coordinates of all the points, but > this doesn't work because of off-points, which I didn't consider at > the time. How do you find this bounding box? What exactly do you mean with 'find'? The algorithm? Just take the extrema of *all* points – for fonts this should be good enough, because it is standard to have points at the curve extrema, thus making the bounding box of the curve identical to the bounding box of the points (both on and off points). > I should note that, in your example, check #3 is too restrictive. > The logic allows for the bottom shape that needs to be separated to > be made up of any number of contours, which allows it to work for > characters with more complex shapes. What exact rule are you referring to? My rule #3 was (3) All points of A are lower than all points of B (or vice versa). which doesn't seem to fit what you are talking about... > I want to clarify: are you adding glyph names in the database as a > requirement for the project? No, I'm not, but I ask you to have this in mind to find a solution that can be easily extended to cover this situation, too (for example, by using an extendable structure instead of a plain variable). Werner
