Looks good to me. + (flag ,procedure? "A function returning the full flag stencil for
this should be ,stencil? - as you can see, there are plenty of properties that have procedure values, but aren't defined as such. +;; Add the stroke to the flag: Load the correct glyph from the font and add it +(define-public (add-stroke-glyph stencil stem-grob dir stroke-style flag-style) If possible, use doc strings rather than comments. On Fri, Aug 29, 2008 at 7:29 PM, Reinhold Kainhofer <[EMAIL PROTECTED]> wrote: > [*] We now have two ways to generate flags: One C++ implementation > (ly:stem::calc-flag) and one pure-Scheme implementation (default-flag). > Both require the same amount of memory and there is hardly any difference > in their runtime. For example, a file consisting of 10,000 eighth notes > (nothing else) needs ~1.5GB RAM and runs for a bit over 3 minutes here, > with the C++ implementation beating the Scheme implementation by mere > 5 seconds: > In C++: > real 3m9.133s > user 3m4.896s > > In Scheme: > real 3m14.016s > user 3m10.024s That's 5 seconds on 180secs - 2%. I find that a lot for just a single property. > Okay to push to master? Yes. > PS: What about the straight flags glyphs that we already designed? Should we > simply drop that and do a pure Scheme implementation with all its drawbacks > (no proper hinting, as pointed out by Werner in Bug #652)? > Werner, should the get_subpath function still be moved from parmesan-macros.mf > to feta-macros.mf, even though it is not really required there? I'm for dropping the MF flags. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
