[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Project - Eliminating grob parents and outside-staff-priority
From: |
Han-Wen Nienhuys |
Subject: |
Re: Project - Eliminating grob parents and outside-staff-priority |
Date: |
Sat, 29 Sep 2012 11:49:35 +0200 |
On Sat, Sep 29, 2012 at 11:35 AM, address@hidden
<address@hidden> wrote:
>
> On 29 sept. 2012, at 10:59, Han-Wen Nienhuys <address@hidden> wrote:
>
>> On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup <address@hidden> wrote:
>>> Han-Wen Nienhuys <address@hidden> writes:
>>>
>>>> In order to do cache invalidation, you will have to construct the
>>>> reverse graph. If A.x depends on B.y, now A points to B. For proper
>>>> cache invalidation, if B.y changes, then A.x becomes invalid. This
>>>> means that A has to store a back-reference to B. Hence all pointers
>>>> have to be stored both ways (including inverting 1-N relations into
>>>> N-1 relations), and the both-way links have to be rewritten correctly
>>>> during line breaking.
>>>
>>> You can assign a generational count to properties. If the generational
>>> count of any dependency is higher than that of the dependent property,
>>> it needs to get regenerated. As long as the dependencies don't get lost
>>> (and we use arbitrary size integers, resetting for each session), this
>>> should be pretty straightforward and not require backwards links. It
>>> "just" requires double-checking your dependencies for change.
>>
>> But since the dependencies are also properties that could be
>> invalidated, you'd have to recurse , so each property access would
>> potentially expand into an almost infinite number of get_property
>> calls.
>>
>> I think it is a much clearer abstraction to decide that each property
>> can only be evaluated once, and that everything should be driven by
>> callbacks. In fact, one thing I would suggest looking at is removing
>> {before,after}_line_breaking which breaks this model somewhat.
>>
>
> I agree 110%. The only corollary I'd add, which comes from my recent work,
> is that pure properties be re-evaluatable all the time (meaning that one
> should be allowed to arbitrarily flush the cache) to store better and better
> approximations of things. For example, if one wants the pure heights of
> cross-staff beamed stems, the approximation one can get before line breaking
> is worse than that which one can get after. After line breaking, one could
> theoretically run beam quanting using the pure heights and actual X
> positions, whereas before, these X positions don't exist. So, pure
> properties in LilyPond become progressively more accurate as they go
> downstream, and once someone is positive that all the information is there to
> evaluate the actual property, get_property (or get_extent or whatever) is
> called.
pure-properties are misnamed. If they are always are recomputed, they
should be called methods or even pure functions and not properties.
Of course, if there is a cache, you have to think about a simple and
rigorous scheme to know when the cache can be thrown away; the real
problem is about caching data based on other grobs, since invalidation
implies a lot more of pointer juggling
> I agree about (before,after)_line_breaking.
>
> The single biggest offenders of this model, in my mind, are to be found in
> the engraver stage. More specifically, I think that if we can get rid of the
> Tweak_engraver such that every property is initialized via the Grob::Grob
> (SCM basicprops) constructor (like in engraver.cc, for example) and not via
> set_property at the engraver stage, everything else will be easier.
You could make a separate routine that prepends sym/value pairs onto
the immutable list; I'm not certain that this would intrinsically buy
you anything, though.
--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
- Re: Project - Eliminating grob parents and outside-staff-priority, (continued)
Re: Project - Eliminating grob parents and outside-staff-priority, Joe Neeman, 2012/09/26
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/26
- Re: Project - Eliminating grob parents and outside-staff-priority, Keith OHara, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, Keith OHara, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, Janek WarchoĊ, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30