On Mar 1, 2012, at 11:52 AM, Han-Wen Nienhuys wrote: > 2012/3/1 Janek Warchoł <janek.lilyp...@gmail.com>: > >> From what i see, the skylines are now more precise than they need to >> be - every glyph has a skyline of 10 or so boxes, even if it's a >> single letter! (see attached) >> I think the proper solution would be to: >> a) set minimal "step" size to 0.2 staffspace (or more in case of bigger >> objects) >> b) change outlines from "stairs" to glued lines (what Joe suggested). >> This would allow for even less "fragments" for each skyline. > > It's neat that you are generating such precise skylines, but can you > show places where this makes an appreciable difference for texts? >
Janek had sent out a couple e-mails before (I can't find them). It makes a significant difference for DynamicText, and I know he has a few examples of lyrics as well where it makes a difference. David's also right about the single high letter and note stem (this was one of Janek's examples). > You could look into some heuristic that limits the number of boxes > depending on their shapes, so it creates a single box for most glyphs. > I agree - there's a lot of room for heuristicking. > For example, you could take the box enclosing the glyph and compare > its area with that of the union of the boxes, and revert to one box if > the difference is less than X percent. > Remembering that 81.2% of all statistics are fabricated on the spot, I'd say that 70% of speed-up work could be done in skyline.cc. I think stencil-integral.cc is as fast as its gonna get. It may help to cache a FT_Face in the Pango_font class as I'm not sure how long it takes to look it up. I'm not convinced after testing that caching font outlines significantly speeds things up - there used to be some code for this, but I've removed it. It can be put back in later if it turns out that after profiling the calls to the functions in freetype.cc sap a lot of time. What I really need help on is profiling. People have so far offered great suggestions on how to do it, but I'm not too good at reading the summaries from profilers to know exactly where the resources are being consumed. If someone sent me a really detailed chart with what resources were consumed on what, that'd help immensely. The only thing that was clear to me was that LilyPond is spending a lot of time in skyline-related functions, but I'm not sure which ones. The skyline class in general looks like it needs a look-over from someone who knows something about CS and optimization. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
