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: address@hidden
Subject: Re: Project - Eliminating grob parents and outside-staff-priority
Date: Sun, 30 Sep 2012 10:01:44 +0200


On 29 sept. 2012, at 19:54, address@hidden wrote:


On 29 sept. 2012, at 19:53, "Keith OHara" <address@hidden> wrote:

On Sat, 29 Sep 2012 10:30:32 -0700, address@hidden <address@hidden> wrote:


The way you're using "tentative" is almost exactly how pure properties are used in LilyPond.

Specifically, 'pure-height being the estimated vertical extent before line-breaking, while 'height is its extent after line-breaking.

If there are distinct properties to describe the position at different stages, then each property can be evaluated just once (as HanWen suggested, and as Mike agreed 100%).

More thinking.  I'm not enthusiastic about stages - it is a top down approach that locks us into certain points of evaluation.  What if we decided to add or get rid of a stage?  Would we need to create things like unpure-pure-containers for various stages?  What qualifies as a stage?  Could users make custom stages?

Furthermore, the idea of properties being pure in LilyPond is impossible to police.  The code almost guarantees that won't be pure, as once the dim_cache_ of a grob is filled, it gives that value instead of the result of a function call (see Grob::pure_relative_y_coordinate, specifically line 350 of grob.cc as of 9e605a1bb6644d89cf110f20cb6d46bb0339fca7).  I like Keith's idea of "tentative" and "permanent".  The model I'm thinking of is:

--) LilyPond evaluates all callbacks as permanent unless tentative is explicitly asked for.
--) Permanent properties are stashed in a cache that cannot be erased.
--) Tentative properties may (i.e. heights) or may not (i.e. color) be cached depending on how we choose to optimize LilyPond.  It is the responsibility of the coder, if she wants an uncached property, to wipe the cache.
--) Most importantly, all notions of pure callbacks disappear.  It is the job of functions to police themselves.  For example, a function Grob::has_full_x can be created to determine if a grob has an X position with respect to the system.  It'd check to see if the dim_cache_[X_AXIS].offset_ of a Paper_column pointing to a real location in memory.  The answer will be false if System::break_into_pieces has been called and true otherwise.  Then, we could do something like:

MAKE_SCHEME_CALLBACK_WITH_OPTARGS (Slur, height, 1, 2, "");
SCM
Slur::height (SCM smob, SCM begscm, SCM endscm)
{
  Grob *me = unsmob_grob (smob);
  if (me->has_full_x ())
    return permanent_height (me);

  int beg = robust_scm2int (begscm, 0);
  int end = robust_scm2int (endscm, 0);
  return tentative_height (me, beg, end);
}

This'd allow to entirely get rid of all the pure callback lists as well as unpure-pure-containers.

--) Both permanent and tentative properties can result in calls to set_property, set_object, translate_axis, and suicide.  All setters should be used sparingly and internally to cache values (like we do for minimum translations, for example).  We can police this via warnings and errors.

Cheers,
MS


reply via email to

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