lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 37 - new work


From: Graham Percival
Subject: Re: Issue 37 - new work
Date: Fri, 28 Jan 2011 21:42:17 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Jan 28, 2011 at 07:26:14PM -0200, Han-Wen Nienhuys wrote:
> On Fri, Jan 28, 2011 at 6:01 PM, Graham Percival
> <address@hidden> wrote:
> > I see nothing wrong with providing "easy-to-use" optimization
> > levels, as long as it's possible to "dig down" and find out what
> > they all do.  I've happily used -O2 for years without once looking
> 
> Quick:  in what case should you use gcc option -ftree-vrp ?

I cannot imagine any case, other than some madman bursting into my
bedroom and threatening me with a chainsaw, in which I would need
to answer this question quickly.  If I had reason to suspect that
-ftree-vrp might be useful, I'd stick it into google and see what
I find.
 
> The -O2 option to GCC demonstrates what I mean.  Nobody knows what the
> levels do, so people settle on either -O2 which is the maximum that is
> not a tradeoff, or no optimization at all.

*shrug*
I have no objection to an "all or none" approach to this
optimization, if an investigation of the options suggests that
there's no useful level between all and none.

> In the case of lilypond, how would someone know which level to choose,
> if it werent either maximum or minimum level?

By reading the documentation.  Trust me, I know how to work on
this part.  :)
One cannot learn how to use lilypond without reading the docs, so
demanding that people RTFM for nonstandard usage isn't a terrible
burden.


Off the top of my head, I can imagine at least 3 useful levels of
optimization.  The default output is the highest quality, of
course.

1. absolute crap output.  All \override and \set and \tweaks are
ignored, all beams are horizontal, strict grid-like notehead
spacing, fixed distance between staves, allow collisions between
noteheads, allow slurs to go through noteheads, etc etc.  Whatever
_can_ be turned off, _is_ turned off.
To make it absolutely clear that this is totally disgusting
output, we automatically make the background color of the PDF or
PNG light pink, or dull brown, or puke yellow/green.

2. decent quality.  Something like the 2.12.3 output, or current
output with #(minimal-breaking) or whatever the lowest-processing
version of vertical spacing is.

3. highest quality.  Use O(n^2) operations for beam collisions, or
multiple passes, or whatever.
* not that we deliberately use silly alogrithms; if we can get
good beam collision avoidance without multiple passes, then of
course we'd hold out for such a patch.

Cheer,
- Graham



reply via email to

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