lilypond-devel
[Top][All Lists]
Advanced

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

Re: Vertical spacing regression !?


From: Arno Waschk
Subject: Re: Vertical spacing regression !?
Date: Tue, 29 Jun 2010 20:23:16 +0200
User-agent: Opera Mail/10.53 (Linux)

Hi Joe and Boris,

On Sun, 27 Jun 2010 19:25:57 +0200, Joe Neeman <address@hidden> wrote:

On Sun, 2010-06-27 at 06:56 -0400, Boris Shingarov wrote:
Hi Arno,

>> Thanks, I've reverted the patch in the meantime. However, the
>> information that you see in annotate-spacing is actually computed after
>> line-breaking,
>
> ok, so why can't it then be taken into account for page-breaking?
The problem is that page-breaking does not come *after* page-breaking.
Well, conceptually, it sort of does.  But the optimization of breaking
is global over the product space of all line breaking possibilities by
all page breaking possibilities.  It is done in the hope to get more
optimal breaks.   The downside is that we are forced to use "height
estimations" instead of real heights of things; otherwise we would need
to do page layout for every possible break configuration, which would be
prohibitively expensive.

while I have a
personal bias against scrapping the vertical layout (since I wrote it),
I do think that it is a big improvement over the previous layout
algorithm and I have heard comments to that effect on the lists too.
Also, the page-turn-breaker can't function without some interaction
between line- and page-breaking.

> Since it more than doubles the computation time (often by far) there
> must be something redundant, no?
No, because the height used in page breaking, is not the actual height;
it is just an estimate (often wrong).

so it seems we need better estimations since the thing now is rather disappointing compared to earlier experience. (I even regret having got used to the "q" chord repeats whcih make my scores impossible to be rendered by 2.12...)

can't we have correct heights say for every bar (which must be computed later anyway) with clever caching so we have them ready when the final layout is made? I see that "removeemptystaves" would make it necessary for calculating several possible heights then, but still I can't see why that should be far more expensive then what we have now...

Actually, in this case it was just stupidity on my part. I was including
into the height-estimate of each system _every_ RehearsalMark in the
whole score, whether it belonged to that staff or not.

does this mean you could provide an improved version of your former patch?

Cheers, Arno
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/



reply via email to

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