Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

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.