[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: anyone notice speed of 2.17.95 on Windows ?
From: |
Keith OHara |
Subject: |
Re: anyone notice speed of 2.17.95 on Windows ? |
Date: |
Sat, 14 Dec 2013 14:58:52 -0800 |
User-agent: |
Opera Mail/12.16 (Win32) |
On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon <address@hidden> wrote:
On Dec 14, 2013, at 9:35 AM, David Kastrup <address@hidden> wrote:
Most of the contortions seem focused about when or when not and how to
pass begin/end columns. It would seem to make sense to turn them into
dynamic parameters *begin* *end* that you can then query with (*begin*)
and (*end*). If (*begin*) returns ##f, we can assume being in a pure
calculation.
That would seem to get rid of most of the current interface
complications.
I can see the utility of having one function instead of two for these things.
The current pure and non-pure functions are often wrappers around a single
internal function that has a bool parameter called “pure”, so this would
eliminate the need for the wrapper functions.
Well, the presence of 'begin' and 'end' parameters is a far less important
distinction, between the pure-estimate and unpure-final versions of a function,
than the vastly different roles of these functions in layout.
When the same code is shared too much between these roles, LilyPond does some
immensely silly things.
DynamicLineSpanner uses the same code for 'vertical-skylines' in both 'pure' and
'unpure' roles. This causes a spanner p<f to generate a detailed skyline for
each distinct 'start' and 'end' column that contains the spanner among the
line-breaking possibilities that LilyPond considers and also for start=0
end=100000 and for start=0 end=2^31 [2]. But the horizontal positions have not
been set when the pure-estimates are requested, so these skylines all describe a
'p' overprinted upon a crushed hairpin and an 'f'.
Several considered line-breaks might have the same 'start' and 'end' around the
hairpin, but the upper-level axis-group structure caches results for each
start/end pair so just one skyline is generated for each distinct pair request.
The path that generates these calls, however, bypasses the cache, and causes
repeated generation of the skyline. (My suggested patch stores the individual
skylines for each Dynamic, so the 'p' and 'f' glyphs are fetched and outlined just
once, and only the skyline-merging to outline the p<f is repeated.)
The operations in side-position-interface, when called as 'pure', compute
locations that are not quite so silly, but not very useful.
The word 'pure' might have too much a connotation as 'good'. Maybe we should
rename 'pure' ->
'shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'
--
The most transparent reorganization might be to have all properties that can
hold data use the usual callback mechanism: where the callback function is used
just once, and the data it returns takes the place of the callback.
The layout engine could use get_property_data() freely, but before it has set
line-breaks the layout engine would refrain from calling any callback functions
directly. Instead of a callback for 'height', layout functions would look up
the grob property 'tentative-height-estimator' where tentative-*-estimators are
always functions that take the start-end columns as parameters.
The tentative-height-estimator for something like a Slur or VerticalAxisGroup would
return its best guess for the height, while the estimator for a Clef would simply
get_property("height") causing its stencil to be formed and leaving the
resulting data in the 'stencil' and 'height' properties for further use.
- Re: anyone notice speed of 2.17.95 on Windows ?, (continued)
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/13
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/13
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?,
Keith OHara <=
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Werner LEMBERG, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Werner LEMBERG, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Trevor Daniels, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/15