[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gets vertical skylines from grob stencils (issue 5626052)

From: address@hidden
Subject: Re: Gets vertical skylines from grob stencils (issue 5626052)
Date: Thu, 1 Mar 2012 12:00:09 +0100

On Mar 1, 2012, at 11:52 AM, Han-Wen Nienhuys wrote:

> 2012/3/1 Janek Warchoł <address@hidden>:
>> 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  I think 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 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]