On Dec 10, 2013, at 11:47 AM, David Kastrup <[email protected]> wrote: > Mike Solomon <[email protected]> writes: > >> On Dec 10, 2013, at 11:27 AM, David Kastrup <[email protected]> wrote: >> >>> Mike Solomon <[email protected]> writes: >>> >>>> On Dec 10, 2013, at 10:36 AM, Keith OHara <[email protected]> wrote: >>>>> >>>>> I did speed-test that patch, but under Linux. Maybe the system >>>>> calls to the font server, to get outlines for the glyphs, take >>>>> longer under Windows. >>>> >>>> One easy way to avoid this is to turn off this feature with >>>> vertical-skylines = ##f for lots of grobs - I do this often for big >>>> scores when I want to compile them fast, but I reactivate the more >>>> accurate vertical skylines for the final version. >>> >>> Sigh. It's stuff like that which really makes me pessimistic about the >>> prospects of LilyPond as serious software. >>> >>> If its developers consider it unusable for serious work out of the box >> >> It’s the opposite - I use the out of the box settings for serious work >> - it’s the unserious playing around that I try to speed up. > > How is "unserious playing around" not part of a serious creative work > flow? >
It is - I misunderstood what you said. For years, starting with Graham Percival, we’ve been kicking the around the idea of invoking LilyPond at various speed/beauty tradeoffs. I am for this, but to date there have been no propositions that gel with the entire community. I have suggested turning off all my sideline work as a default, but people feel this would not be the best option, so for now, we have it all, which is also not the best option. I stand by Graham’s idea. >> I’ve said on several occasions that I’m indifferent deactivating some >> or all of vertical skylines as a default. Several people are against >> this deactivation (notable Janek). > > If we have more than a factor of 2 in timing involved between Linux and > Windows, then we do too much repeated processing in the font server. > >> I’d be interested in gradations of UI options called perhaps: >> >> \faster-but-uglier >> \a-lot-faster-but-a-lot-uglier >> \ridiculously-fast-and-heinously-ugly > > Nope. In this case, the answer is to cache frequently accessed > information instead of requesting it again and again. > > We don't want to give people a choice between different ways in which > LilyPond will be bad. We just don't want LilyPond to be bad. > In my initial patches, which involved caching everything, there was no appreciable speed-up on Mac and Linux. I did not test it on Windows, but I don’t remember Windows users (Janek) reporting back problems). I would be interested to do rigorous testing on Windows. It is not hard to do - it requires creating a Scheme hash linking glyph names to skylines. I still advocate allowing users to specify a speed/beauty tradeoff, which can be done in concert with optimization to LilyPond’s core. Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
