Feels like the principle of
iterating through the array of elements to be drawn now needs to become more
comprehensive.
When drawing a note, you draw it’s stem and
then any tails needed, except if the next note in the array has it’s ligatures
(aka beams) extended back to this notes tail.
Also you don’t draw a notes tails if it is
to extend back to the previous note but you do need to know what type of note
the previous one is and where it’s stem is.
So a note needs to know the properties of
the note to it’s right, and to it’s left in order to draw itself.
Now this light bulb has gone on, the
approach of adding context through parameters to the paint() method could get
quite clumsy. It may be better to allow each note access to read the manuscript
it’s part of.
Following this approach would mean a note
would fix up to the array of notes, find out it’s index in the array, then use
that to access it’s neighbours. This could be quite expensive in terms of CPU
cycles to perform array lookups as it’s a serial scan through an array to find
it’s index.
Should we worry about CPU cost in this day
and age? How much will performance be dragged down by if there’s 200 elements
in the array?
A more performant approach would be to
provide the references to the next and previous notes, and staff elements (you
need to know if your neighbor is a bar line as that changes your drawing behavior
too). This is what’s been implemented in the code today, for now, using some
funky referencing while performing a single scan of the staff elements array.
My remaining concern is what else will we
discover needs to be provided at paint() time in the way of context that will
continue to extend complexity here? I wonder how long it will take me to get up
to speed on this piece of code in 3 years time between this blog, documentation
and source comments!
No comments:
Post a comment