lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Project - Eliminating grob parents and outside-staff-priority


From: David Kastrup
Subject: Re: Project - Eliminating grob parents and outside-staff-priority
Date: Wed, 26 Sep 2012 14:13:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

"address@hidden" <address@hidden> writes:

> On 26 sept. 2012, at 13:39, David Kastrup <address@hidden> wrote:
>
>> It sounds to me like it would make more sense that we improve our
>> cache invalidation strategy where it goes wrong
>
> There is currently no cache invalidation strategy.

Sounds like we found the place where it goes wrong.

>> rather than shifting the
>> problem around in increasingly complex manners.
>
> There is currently no way in LilyPond to trace what properties depend
> on what properties.  So if we want to invalidate the cache of property
> X, it is very difficult to invalidate the caches of properties that
> depend on it.  This is made considerably easier if side-positioning is
> streamlined.  When a grob X's side position changes for a given axis,
> iterate over its side-position elements and recalculate their offsets.
> That's one of the main reasons I want to make this change.

What we need to arrive at is a situation where somebody without a clue
starting to write stuff will more likely than not get a whole lot of
things working right without realizing it, rather than getting a whole
lot of things working wrong without realizing it.

Which apparently is what is happening to Marc right now.  He is working
on a simple problem, and it fails for complex reasons.  And that means
the current design of our backend is bad.

Conceptually simple problems need to map to conceptually simple
solutions.  If they don't, our APIs suck.

> I think the change decreases complexity as it makes LilyPond more
> predictable and boring - objects side position based off of other
> objects and that's it.  No need for side-position, parents and
> outside-staff-priority.

parents are used for a _lot_ of positioning, and for example the
determination of a common grob parent is an _efficient_ operation.  So
it might make sense to solve the problem you are thinking of via
artificial/grouping parents.  I can't vouch for it, obviously, as the
backend is mostly opaque to me right now.  But it is a possibility.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]