<div dir="ltr"><div>I have pushed a branch called rewaveview to origin(official ardour repository)</div><div>that started out initially as an effort to address the long standing bug #6478.</div><div><br></div><div>In trying to understand the issue/s there were a number of things I thought</div><div>could be improved so I ended up rewriting/redesigning some of the aspects of</div><div>rendering the canvas and waveforms.</div><div><br></div><div>I have not been able to reproduce the crashing issue in the rewaveview branch</div><div>as I can(eventually) in master, but as it is fairly hard to reproduce I would</div><div>like some further testing and feedback on the branch before hopefully</div><div>proceeding to merge/commit to the master branch after working through any</div><div>(hopefully minor) issues. As although I've done many hours of testing it is a</div><div>fair bit of new code so there is the potential for a different set of issues</div><div>and or simple typos/oversights etc.</div><div><br></div><div>The first main change is to coalesce changes to the canvas. Mouse and Key</div><div>driven events have a higher priority than rendering the canvas so if there is a</div><div>consecutive sequence of events that result in a change in state of the canvas</div><div>then rendering the result of those changes is often blocked until a pause in</div><div>the event stream and sometimes in the case of a series of mouse driven events</div><div>until after the last event, even though the last state is the only state that</div><div>gets rendered.</div><div><br></div><div>This results in a lot of superfluous processing taking place in</div><div>Editor::visual_changer and it is noticable in the jumps for instance when</div><div>holding down the -/+ keys to zoom, zooming with the mouse wheel or using ruler</div><div>drag zoom. Coalescing further canvas changes after the first is rendered and</div><div>then processing those changes once(and re-rendering) results in a much smoother</div><div>and predictable canvas zooming/scrolling experience and a noticably higher</div><div>frame rate when performing those operations.</div><div><br></div><div>The other main change is to introduce an interface that canvas items can</div><div>implement so they will be notified when a change to the canvas or items occurs</div><div>and they are determined to be located in the visible canvas area. This is only</div><div>implemented for WaveView at the moment and it allows the waveform to be drawn</div><div>in another thread/s much earlier than previously, so that by the time the</div><div>canvas renders for display the image is usually finished and you don't get</div><div>much flickering of the audio regions.</div><div><br></div><div>The design and implementation of the WaveView class has changed a fair amount.</div><div>The waveform drawing itself should be unchanged but the handling of threaded</div><div>drawing and the supporting classes are different.</div><div><br></div><div>The caching of images in WaveView was improved so that all caching operations</div><div>are in constant time. I thought this was necessary as in the master branch when</div><div>the cache is full(which it becomes quite quickly) as it can slow rendering down</div><div>enough that it was worth fixing.</div><div><br></div><div>Another change I made to the caching of images is being able to add them to the</div><div>cache as soon as the request is made and they are unfinished, as it means that</div><div>usually only one image is drawn for WaveViews with similar properties and</div><div>it reduces the amount of drawing for loop/clip based compositions for instance.</div><div><br></div><div>There are a few more optimizations/tricks included in the changes and when</div><div>threaded rendering is enabled it will use cpus/cores - 1 threads for waveform</div><div>drawing which is useful in some circumstances to reduce draw time and</div><div>flickering.</div><div><br></div><div>I'm going to be travelling for the next 10 days, so I may not have much</div><div>opportunity to respond to feedback/issues until after I get back but I have</div><div>created a report in the bug tracker to track any issues:</div><div><br></div><div><a href="http://tracker.ardour.org/view.php?id=7309">http://tracker.ardour.org/view.php?id=7309</a></div><div><br></div><div>I attached to the report some logging/trace output of various of my testing</div><div>scenarios for master and rewaveview that can be analyzed with</div><div>chrome/ium://tracing if anyone is interested in those.</div><div><br></div><div>There are a few further changes that will help to improve canvas performance</div><div>that I know of, but this is a very good start I think.</div><div><br></div><div>Depending on how testing of the branch goes, we can discuss when/if it can be</div><div>merged into master after I get back, I just didn't want to sit on this code if</div><div>there is a possibility of fixing #6478 before the next release.</div><div><br></div><div>Tim</div></div>