Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 15, 2013, at 12:58 AM, Keith OHara <address@hidden> wrote:

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.

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'

I prefer the second name, with the corollary that pure heights and pure anythings are the largest implementation of a basic strategy all over the code base, which is:

1. elaborate several options
2. score them
3. pick the one with the highest score

This happens for slurs, beams, ties, and line breaking.  In the case of line breaking, the elaboration of the options entails making estimates, which is why we calculate pure heights.

--
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.

This is indeed transparent, but given that a single object can return many pure heights based on the begin/end values being used or based on how far downstream we are, it’s not clear what this property would look like.

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.

This seems not too far from what we’re doing now, but it adds a lot more properties.

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.

This seems to get the same result we have now while adding a lot of extra properties.

I like the idea of their being a single property that is honed in on with successive estimates until we get the perfect value.  This is how I do a Sudoku - I pencil the guesses in the squares until I get the actual value and then erase all the estimates and write the good value.  Something about using the container (the property) as a holder of the estimates and the final item itself feels sound design-wise.

Cheers,

MS