Re: Logging Library-GSOC
Hi Armin, *>However, I could see how e.g. the usage of `FT_COMPONENT` could be slightly altered (or an additional macro introduced) if that helps with moving more functionality into the logger.* Please, could you provide more information on this... Thanks, Priyesh On Sun, Jun 14, 2020 at 3:24 PM wrote: > > No, I haven't thought in that direction as according to the requirements > least > > coupling is favorable... > > I think (but happy for everyone with other opinions to chime in + discuss) > at this point the only real hard constraint in that regard is that we want > to wrap the logger into FreeType specific macros and not expose it directly > in the core codebase. In addition, `FT_TRACE*` and `FT_ERROR` should not > be replaced or changed (unless there is a really good reason that pretty > much everyone agrees on). However, I could see how e.g. the usage of > `FT_COMPONENT` could be slightly altered (or an additional macro > introduced) if that helps with moving more functionality into the logger. > > As I understand it, parts of this project is to generally enhance tracing > + logging within FreeType. Apart from platform independent write-out, > timestamps, custom callbacks, etc ... this _could_, in my opinion, also > include moving the handling of logging + tracing out of the core codebase > (if / as much as this is reasonable) as this could open up a lot more > flexibility down the road (depending on the logging library in question + > should be discussed separately). I believe that, once we are able to hook > a specific logger into FreeType with just a few macros, replacing that > logger might become a reasonably easy task, should requirements change. > Thus, unless Werner disagrees, I believe it would be interesting to explore > that option and understand if / how easily this can be done (and to what > extent). > > Best > Armin > >
Re: [Freetype-devel] Re: GSOC - Distance Fields
>> How many times do you have to solve this for each glyph?
>
> A considerable amount of time. If you want the exact number it is
> `width * rows * number_of_conic_curves', without any optimization.
Ouch.
>> How many different solutions (aka curve points) do you have to find
>> for each curved segment? I figure there are a lot of grid-curve
>> pairs to enumerate with most of the curve segment sampled fairly
>> frequently...
>
> This can be as many as 65536, this is tied to the width and rows of
> the bitmap being generated. The more the resolution the more curve
> points have to be checked.
>
> And yes there are various grid points which correspond to the same
> curve point. If the grid point lies on the same perpendicular from
> the curve then their curve point might be the same.
>
>> Do you see where I am going?
>
> I'm not sure. Are you telling me to use the results of the previous
> iteration?
I think he means that the code must be optimized as much as possible
to get fast rendering. In particular, it is important to find and
eliminate hotspots.
> I have fixed the overflow, it was just my stupid calculation
> mistake. [...]
Excellent. Will check the code soon.
> I have updated the repositories and perhaps I can now start
> integrating it into freetype?
Certainly. Please create a branch for your stuff and try to add your
code in small (if possible), concise commits. This doesn't hold for
new files, which should be simply added as-is.
Some comments to your code.
* What does line 38 do?
https://github.com/preversewharf45/freetype2-sdf/blob/dcedba69423fc169a9ca95b6391902e1cf27e0b6/src/sdfgen.c#L38
It seems that `pup` and `roots` aren't used at all.
* Function `get_min_conour` should probably be called
`get_min_contour`. Otherwise please explain in a comment what
'conour' means.
* Our coding style is to use
if ( foo )
bar;
for single-line statements instead of
if ( foo )
{
bar;
}
* Have you thought about iterative solutions to get the cubic roots
necessary for the quadratic case? Maybe this would be faster.
* Maybe there is a mathematical approximation to solving the
fifth-grade polynomial. I don't mean a better root-finding
algorithm but a simpler representation of the curves so that we can
avoid a fifth-grade polynomial altogether. The same holds for the
third-grade equation, of course.
* Typo: s/simliar/similar/
* If you end a comment with a full stop, please start it with an
uppercase letter so that it becomes a normal English sentence.
Werner
PS: Did you have a look at Behdad's `GLyphy` implementation?
Re: [Freetype-devel] Re: GSOC - Distance Fields
> *I am asking you to do some performance analysis. Specifically, would* > *you** please profile a curve and a straight segment to compare?* Sure, here is the average of 1 million iteration of computing shortest distance from a point to both types of curves and line segments: (using -O3 optimization, measured using chrono library) A) Line Segment: ~0.32 microseconds B) Conic Bezier: ~1.08 microseconds C) Cubic Bezier: ~1.25 microseconds [I have also attached the gprof output in case you are interested. Note that the gprof output is without any compiler optimization] > *We need to know if it is worth simply splitting the curve into a large* > *number of straight segments. How many straight segments we can afford* > *and still beat the exact solution.* In my opinion it's not worth splitting the curves into line segments. But if there is a way to not check each and every line segment, then it might be worth giving it a try. > *Sure, but please use your dedicated branch.* Yes, I will do that. Anuj Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls us/call us/call name 57.03 1.38 1.38 8378453 0.16 0.16 ft_trig_pseudo_polarize 16.12 1.77 0.39 100 0.39 2.38 get_min_distance [for cubic curves] 13.64 2.10 0.33 153570100 0.00 0.00 FT_MulFix_x86_64 4.55 2.21 0.11 100 0.11 0.11 FT_Vector_NormLen 2.89 2.28 0.07 8378453 0.01 0.01 ft_trig_prenorm 1.86 2.33 0.05 7378505 0.01 0.01 FT_DivFix 1.65 2.37 0.04 8378505 0.00 0.18 FT_Vector_Length 1.24 2.40 0.03 main 0.41 2.41 0.01 8378453 0.00 0.00 ft_trig_downscale 0.41 2.42 0.01 FT_Vector_Rotate 0.21 2.42 0.01 FT_MulFix % the percentage of the total running time of the time program used by this function. cumulative a running sum of the number of seconds accounted seconds for by this function and those listed above it. self the number of seconds accounted for by this secondsfunction alone. This is the major sort for this listing. calls the number of times this function was invoked, if this function is profiled, else blank. self the average number of milliseconds spent in this ms/callfunction per call, if this function is profiled, else blank. total the average number of milliseconds spent in this ms/callfunction and its descendents per call, if this function is profiled, else blank. name the name of the function. This is the minor sort for this listing. The index shows the location of the function in the gprof listing. If the index is in parenthesis it shows where it would appear in the gprof listing if it were to be printed. Copyright (C) 2012-2020 Free Software Foundation, Inc. Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. Call graph (explanation follows) granularity: each sample hit covers 2 byte(s) for 0.41% of 2.42 seconds index % timeself childrencalled name [1] 99.40.032.38 main [1] 0.391.99 100/100 get_min_distance [2] --- 0.391.99 100/100 main [1] [2] 98.10.391.99 100 get_min_distance [2] 0.041.46 8378505/8378505 FT_Vector_Length [3] 0.330.00 153570100/153570100 FT_MulFix_x86_64 [5] 0.110.00 100/100 FT_Vector_NormLen [6] 0.050.00 7378505/7378505 FT_DivFix [8] --- 0.041.46 8378505/8378505 get_min_distance [2] [3] 62.00.041.46 8378505 FT_Vector_Length [3] 1.380.00 8378453/8378453 ft_trig_pseudo_polarize [4] 0.070.00 8378453/8378453 ft_trig_prenorm [7] 0.010.00 8378453/8378453 ft_trig_downscale [9] --- 1.380.00 8378453/8378453 FT_Vector_Length [3] [4] 57.01.380.00 8378453 ft_trig_pseudo_polarize [4] --- 0.330.00 153570100/153570100 get_min_distance [2] [5] 13.60.330.00 153570100 FT_MulFix_x86_64 [5] --- 0.110.00 100/100 get_min_distance [2] [6]
Re: [Freetype-devel] Re: GSOC - Distance Fields
On Sun, Jun 14, 2020 at 12:32 AM Anuj Verma wrote: > A considerable amount of time. If you want the exact number > it is `width * rows * number_of_conic_curves', without any > optimization. I am asking you to do some performance analysis. Specifically, would you please profile a curve and a straight segment to compare? > > Do you see where I am going? > > I'm not sure. Are you telling me to use the results of the previous > iteration? We need to know if it is worth simply splitting the curve into a large number of straight segments. How many straight segments we can afford and still beat the exact solution. > I have updated the repositories and perhaps I can now start integrating it > into freetype? Sure, but please use your dedicated branch. Best, Alexei
RE: Logging Library-GSOC
> No, I haven't thought in that direction as according to the requirements least > coupling is favorable... I think (but happy for everyone with other opinions to chime in + discuss) at this point the only real hard constraint in that regard is that we want to wrap the logger into FreeType specific macros and not expose it directly in the core codebase. In addition, `FT_TRACE*` and `FT_ERROR` should not be replaced or changed (unless there is a really good reason that pretty much everyone agrees on). However, I could see how e.g. the usage of `FT_COMPONENT` could be slightly altered (or an additional macro introduced) if that helps with moving more functionality into the logger. As I understand it, parts of this project is to generally enhance tracing + logging within FreeType. Apart from platform independent write-out, timestamps, custom callbacks, etc ... this _could_, in my opinion, also include moving the handling of logging + tracing out of the core codebase (if / as much as this is reasonable) as this could open up a lot more flexibility down the road (depending on the logging library in question + should be discussed separately). I believe that, once we are able to hook a specific logger into FreeType with just a few macros, replacing that logger might become a reasonably easy task, should requirements change. Thus, unless Werner disagrees, I believe it would be interesting to explore that option and understand if / how easily this can be done (and to what extent). Best Armin
Re: Logging Library-GSOC
Hi armin, >*Thanks for your update & write-up, looks promising :) I agree with your approach of trying to find the most lightweight C logger that does the job* Thanks for reviewing the report... Regarding Qus 1) *>do you plan to mainly using the logger to write to files and an equivalent of `stderr` consistently across multiple platforms * Yes, this was my plan (plus the feature of dynamic change of log levels and dynamic log redirection). *>do you also plan to use it to replace some of the handling that's currently done within FreeType (like checking + parsing log levels + components, etc) with calls to that library? I believe it >would be especially interesting if we managed to move some of the components handling out of FT and into that external piece. Not sure however, if any of these libraries have a somehow >direct mapping of how components (modules) are used for tracing within FT currently (essentially, all components/modules can be configured with their own trace level). * No, I haven't thought in that direction as according to the requirements least coupling is favorable... But, I think it is a nice idea to completely use the external logger if some user wants the feature of printing log messages to file (otherwise they can use the normal debugging facility provided by FreeType), However, for that, we will require a logging library that provides a feature to create our own log levels (so that we could map 8 trace and other log levels which FreeType uses). But as far as I have seen only zlog provides the feature of defining our own log levels... Regarding Qus 2) *>have you looked into log4c at any point? Not saying it is what FreeType needs but something that worked reasonably well for me a while ago; might be a lot bigger than what we need or >have other downsides, just asking b/c I couldn't see it in your list. * I haven't looked into log4c till now... I will have a look at log4c and update it's pros and cons (according to me and the requirements) in next week's progress report... Thanks, Priyesh On Sat, Jun 13, 2020 at 8:39 PM wrote: > Hi Priyesh, > > > I have updated the progress report for this week @ > > > https://docs.google.com/document/d/1X5ApmVxz0pXcGUCF9Um5VhVZV403LWDIYFbKYg1aLoQ/edit?usp=sharing > > Thanks for your update & write-up, looks promising :) I agree with your > approach of trying to find the most lightweight C logger that does the job, > just two quick questions about your work: > > (1) do you plan to mainly using the logger to write to files and an > equivalent of `stderr` consistently across multiple platforms or do you > also plan to use it to replace some of the handling that's currently done > within FreeType (like checking + parsing log levels + components, etc) with > calls to that library? I believe it would be especially interesting if we > managed to move some of the components handling out of FT and into that > external piece. Not sure however, if any of these libraries have a somehow > direct mapping of how components (modules) are used for tracing within FT > currently (essentially, all components/modules can be configured with their > own trace level). > > (2) have you looked into log4c at any point? Not saying it is what > FreeType needs but something that worked reasonably well for me a while > ago; might be a lot bigger than what we need or have other downsides, just > asking b/c I couldn't see it in your list. > > Best > Armin > >
Re: Logging Library-GSOC
> I find it a *very* bad idea to have code in FreeType that would > write to a file. Specially bad if that can be controlled by an > env-var. Interesting. Please explain. Do you fear security issues? > I still think what's desired can be done best by just revamping and > writing custom code in FreeType itself. Yes, this is another possibility. We haven't yet decided how to proceed; Priyesh is still in the investigation phase. Werner
