On Feb 7, 2012, at 6:47 PM, m...@apollinemike.com wrote:
>
> I did some experiments with caching that are up on:
> dev/skylines-cached
Hey all,
Fresh branch up at dev/skylines-cached. This patch should only increase
compilation time of a LilyPond score by 1-2 seconds for every minute.
In order to test it, YOU MUST RUN:
make clean
./autogen.sh --disable-optimising
make all
Otherwise, LilyPond will complain about not being able to find stuff (I've made
changes to GNUmakefile.in) and/or segfault.
I need a few things from interested parties:
1) Run large scores and tell me if they look good and/or if they take a long
time.
2) Skim stencil-integral.cc and let me know if the comments are clear enough
to describe what it is doing.
3) Skim stencil-integral.cc and let me know if the object-oriented approach is
too flimsy. I basically throw everything in structs and use no constructors,
which is not unlike beam-quanting.cc, but it would likely make an intro to CS
instructor blush.
4) The code in stencil-integral.cc is very fragile. It relies on hardcoded
assumptions about how stencils are constructed. This is not unlike
stencil-interpret.cc. This is not good, as it means that a user can do stuff
like (ly:make-stencil '(scale-stencil 4 4 4 4 4 4 (draw-line 1 1))) and the
code will go haywire. There is not really anything I can do in this patch to
prevent that, but in a subsequent patch, I (or someone else) will need to write
a stencil API (which will likely result in getting rid of a couple more
stencils - polygon, for example, can be rewritten using paths) and have an
"assert-stencil-well-formedness" command that verifies that a stencil's expr_
only contains valid info. That said, if anyone has comments on how to better
handle the handling of SCM data, they are certainly welcome.
5) Comment on the build system stuff. I have no clue how anything works in
build-related tasks, so if there's a better way to accomplish what I'm doing in
the makefiles, lemme know.
6) For the brave of heart, check out axis-group-interface.cc
add_grobs_of_one_priority. I think it does what I want it to do in terms of
correctly using vertical skylines instead of boxes, and the visual results seem
to confirm this, but it is certainly one of the more sensitive areas of the
code and I'd appreciate a couple read-throughs from people who know this corner
of the code.
After I get some general feedback, I'll throw the patch up on Rietveld so
people can dig into the nitty gritty.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
