[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Project - Eliminating grob parents and outside-staff-priority
From: |
address@hidden |
Subject: |
Project - Eliminating grob parents and outside-staff-priority |
Date: |
Wed, 26 Sep 2012 13:15:11 +0200 |
Hey all,
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.
To start this process, I'd like to expand the role of the
side-position-interface significantly. All grobs would use this interface for
their X and Y offsets and they would have two different grob arrays for X and Y
side-position-elements. This would allow me to eliminate two things:
1) parents. Grobs are X/Y aligned to parents, but these parents could be
elements in the side-position-elements array. Functions like get_parent, which
could be kept around for legacy reasons, could return the first element of
these arrays for a given axis and raise a warning if there are multiple
elements.
2) outside-staff-priority. Saying a grob has outside staff priority is the
same thing as saying that a grob has as its Y side support elements all
inside-staff grobs plus all grobs with lower outside staff priority. A
callback creating the side-position-elements arrays could do the sorting that
takes place in Axis_group_interface::skyline_spacing.
The benefits of this are twofold:
1) All work on a multi-pass algorithm could be done with respect to
side-positioning, making it simpler to find bugs and modify code.
2) A call to translate_axis in avoid_outside_staff_collisions would be
eliminated, and translate_axis is bad: it goes against the callback model at
the core of LilyPond layout.
The disadvantage is that this results in the construction of many more skylines
(one for each call to Side_position_interface::skyline_side_position). How
this will impact performance is uncertain, but it'd probably require more
optimization in skyline.cc and/or caching of skylines.
Before I do this, which will take me several months, does anyone have any
objections? Do people think it's a good idea?
Cheers,
MS
- Project - Eliminating grob parents and outside-staff-priority,
address@hidden <=
Re: Project - Eliminating grob parents and outside-staff-priority, Joe Neeman, 2012/09/26