Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Sat, 14 Dec 2013 23:57:20 -0800, Mike Solomon <address@hidden> wrote:

> On Dec 15, 2013, at 12:58 AM, Keith OHara <address@hidden> wrote:
>
> > 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.

There would be no more 'pure properties' as you use that term.
The property 'height' would give the final height.
If the object changes height based on layout, 'height' would be a callback.

Code that works while layout is tentative would not call callbacks,
but could lookup a property 'height-estimator' that links to the pure_height() 
function.

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

Extra properties on those Grobs that use them, in place of the 
unpure-pure-containers.
Reorganization for transparency makes complexity visible.

> I like the idea of there being a single property that is honed in on with 
> successive estimates until we get the perfect value.

But so far, we do not use the previous estimate of a property to inform the 
next estimate.  In fact, with only one slot to hold either the property value 
or the function to compute it, Grobs keep secret any progress they have made 
toward a better estimate, and even forget it themselves.

Simple properties like 'height' could hold either data or simple callbacks that 
are executed once, with these callbacks allowed to *pull* information from 
other grobs and cause their callbacks to execute as well.

Separate function-properties like 'height-estimator' could provide estimates 
when we must avoid forcing other decisions.  They could use /data/ in other 
Grobs' properties, but not callbacks.  These function-properties belong to the 
Grob, so can write the result to its 'height when that estimate is good enough 
to share.  You have wanted to use a preliminary shape for cross-staff slurs to 
inform layout, for example.

The code re-shaping things like Slurs after page-spacing could *push* an 
improved shape onto the 'stencil' and 'height' properties.

> Something about using the container (the property) as a holder of the estimates 
> and the final item itself feels sound design-wise.

At the moment, the property does not hold any estimates; it holds either the 
final data or various functions to fetch the data, and some of these functions 
operate under subtly different rules, both in your unpure-pure-container system 
and Joe's former system.

This subtleties confuse people: issues 3512 and 3482, and the difficulty I had 
in this thread understanding that the same function was called multiple times 
to repeatedly build 'vertical-skylines around each letter.