On 26 sept. 2012, at 13:39, David Kastrup <d...@gnu.org> wrote: > "m...@mikesolomon.org" <m...@mikesolomon.org> writes: > >> As was the case in a few of my previous projects, before I start >> something new I make architecture changes that facilitate my work. >> Working on 2801, I've realized that any multi-pass algorithm for the >> spacing of grobs is difficult because results of callback calculations >> are always cached. So triggering callbacks a second time is, in the >> current architecture, impractical and requires a fair bit of kludgery. > > [...] > >> performance is uncertain, but it'd probably require more optimization >> in skyline.cc and/or caching of skylines. > > It sounds to me like you consider caching a bad idea so you want to > remove it, and to make this removal feasible you think you will be > required to do caching. >
You're right - I explained myself poorly. The caching of skylines would come from similar content. i.e. if Skyline X == Skyline A and Skyline Y == Skyline B and we have already measured the distance between A and B, use that as the distance between X and Y. Here, equality is defined as having buildings with the same start_, end_, slope_ and y_offset_. So it's a different type of caching than the caching of grob properties. > 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. > 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. 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. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
