Optimize rendering logic

[GoogleCodeExporter]

I was seeing that for every render of the editor window, all notes in the 
active instrument difficulty are drawn, including the ones that would be 
clipped entirely by Allegro.  This does cause some notable overhead in that in 
normal cases, the majority of a chart will not be rendered at any given time.  
Other items such as solo markers are drawn even if not necessary, but these are 
computationally cheap because they are only one primitive (rectangle).  Notes 
are more computationally expensive and involve a multiple primitive shapes per 
gem.

If logic could be added to skip the processing of notes that would be off 
screen, it may improve EOF's performance.  Even a marginal efficiency boost may 
help prevent computer lags from other applications from causing EOF to stutter 
or desync.

One approach might be to determine the start->stop span of time for the current 
visible portion of the editor window.  If a note's timestamp is earlier than 
the start time (minus an offset to account for notes whose outlines are earlier 
but would still be visible based on the current zoom level) of the editor 
window, that note can be skipped instead of rendering it to be clipped.  If the 
note's timestamp is later than the end time of the editor window, that note and 
all others in the notes array can be skipped.

Note tails and lyric notes would need different logic, because they can enter 
the visible area even if they start and/or stop before/after the visible area.

Original issue reported on code.google.com by raynebc on 15 Jun 2010 at 8:44

[GoogleCodeExporter]

eof_note_draw() and eof_note_draw_3d() are the functions that would need to be 
optimized.  They can check to determine whether the entire note was clipped, in 
which case if a note clips for being after the viewing window, nonzero can be 
returned and the calling function can know to stop rendering notes in the list.

Original comment by raynebc on 29 Jul 2010 at 12:17

• Changed state: Started

[GoogleCodeExporter]

I'm also not sure I implemented the end render clipping signal correctly in 
eof_lyric_draw_truncate().  I need to determine the timestamp of the left and 
right edge of the window to detect clipping.

Original comment by raynebc on 29 Jul 2010 at 12:20

[GoogleCodeExporter]

r261 optimizes the clipping logic for the editor and 3D windows.

Original comment by raynebc on 29 Jul 2010 at 11:17

[GoogleCodeExporter]

Potentially, there may still be slight speed gains to be had by optimizing 
eof_render_lyric_preview().  The rendering of the fret catalog isn't important 
because in practice, a fret entry is going to be pretty short.

Original comment by raynebc on 29 Jul 2010 at 11:37

[GoogleCodeExporter]

Also, it occurred to me that further improve the 3D rendering, some logic could 
be added to determine if the notes are too far ahead to see.  Since the 3D 
panel only shows about 6-7 beats of notes, most of the last->first note 
rendering can be skipped.

Original comment by raynebc on 15 Aug 2010 at 5:34

[GoogleCodeExporter]

r299 adds some more speed optimizations to the editor window rendering, 
specifically the second markers and beat markers.

Original comment by raynebc on 16 Aug 2010 at 2:20

[GoogleCodeExporter]

Since eof_determine_piano_roll_left_edge() appears to be working as intended, 
this could provide a good means for skipping rendering of objects whose 
timestamps are earlier than the left edge of the editor window with regard to 
the current seek position.

Original comment by raynebc on 23 Sep 2010 at 3:38

[GoogleCodeExporter]

Creating a function eof_determine_piano_roll_right_edge() would probably also 
be useful, as clipping could be determined before the math to transform to a 
screen coordinate is performed.

Original comment by raynebc on 27 Sep 2010 at 7:08

[GoogleCodeExporter]

r409 added some more optimizations to the second marker rendering, which will 
now starts rendering at the first second marker beyond the left visible edge of 
the editor window.

Original comment by raynebc on 30 Sep 2010 at 11:22

[GoogleCodeExporter]

r421 makes some more optimizations, allowing processing of notes/lyrics/solos 
to be skipped if they are left of the visible edge of the editor window.

Original comment by raynebc on 1 Oct 2010 at 10:00

[GoogleCodeExporter]

After doing some work with the fret catalog, it appears there's a minor amount 
of room for improvement in eof_render_note_window():

*It currently tries to render all beat markers even when they aren't visible.
*It checks all lyrics/notes to see if it falls within the fret catalog's start 
and stop positions.  Since notes/lyrics are kept sorted now, it can break from 
the loop if a lyric is beyond the end position of the catalog entry.

The optimized editor window rendering logic could probably gleaned for some 
appropriate optimizations for the catalog rendering.

Original comment by raynebc on 27 Nov 2010 at 8:47

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

r603 adds those optimizations to the note window rendering.

Original comment by raynebc on 29 Nov 2010 at 11:10

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

The fret catalog and editor window rendering have some overlap in logic 
(rendering the fretboard and notes/lyrics).  Perhaps this common logic could be 
separated into a separate function and used multiple times in order to keep it 
easy to maintain, ie. for new track formats or instances where more than 5 
lanes are rendered.

Original comment by raynebc on 30 Nov 2010 at 7:26

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

r610 removes a couple hundred lines of code by altering the note rendering 
logic to support writing to the editor window or the note window.

A similar consolidation can be done for the lyric rendering:
eof_lyric_draw() is currently being kept as a way to render the pen note (since 
eof_lyric_draw_number() only works for lyrics that were already added to the 
lyric track), but the clipping optimizations could be added, along with a 
parameter to define which window is being written to.  An updated 
eof_lyric_draw_truncate() function could be updated to call eof_lyric_draw(), 
allowing the actual rendering logic to be removed.

The actual clipping window that is used by Allegro could be manipulated in 
eof_lyric_draw() instead of eof_lyric_draw_truncate(), after which the latter 
could be renamed to eof_lyric_draw_number() or something similar.

Original comment by raynebc on 6 Dec 2010 at 11:33

[GoogleCodeExporter]

On the note of clipping, eof_lyric_draw() could be passed the timestamp of the 
next lyric (or 0 if rendering the last lyric or the pen note).

Original comment by raynebc on 7 Dec 2010 at 1:16

[GoogleCodeExporter]

r611 makes the proposed changes to the note window lyric rendering.  An added 
benefit of having the fret catalog use the same render logic is that special 
items such as HOPO on/off notes, percussion notes and vocal slides now render 
in the fret catalog as they do in the editor window.

The next step would probably be to remove duplication in the rendering of the 
fretboard lanes themselves, although this will have much less impact on the 
size of the code base.  In any case, the practice of having one 2D note render 
function for each track format (legacy, vocal, pro guitar) will make it much 
easier to maintain and improve EOF.

Original comment by raynebc on 7 Dec 2010 at 9:12

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

I could also optimize eof_lyric_draw() a little further by adding detection for 
clipping that is to the left of the visible area.  This would require using 
text_length() to check if a lyric off the screen rendered onto the screen, 
checking the end position of the lyric note and checking if the next lyric is a 
pitch shift whose position is at or after the left edge of the visible area 
(the vocal slide would be visibly rendered).

Original comment by raynebc on 7 Dec 2010 at 9:25

[GoogleCodeExporter]

r614 adds the fore-mentioned optimization to eof_lyric_draw and removes 
duplicated logic from the note window rendering.

Original comment by raynebc on 8 Dec 2010 at 10:45

[GoogleCodeExporter]

r617 optimizes the 3D tail rendering logic.  At this point, I think that pretty 
much covers everything (3D window, note window, editor window) so I'll consider 
this enhancement complete.

Original comment by raynebc on 9 Dec 2010 at 8:52

• Changed state: Fixed