<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 8:09 AM, John Emmas <span dir="ltr"><<a href="mailto:johne53@tiscali.co.uk">johne53@tiscali.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="im"><br>
----- Original Message -----<br>
From: "Paul Davis"<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
that said, nick mainsbridge did come up a way (a rather obvious way, in<br>
retrospect) for us to use the canvas and make this work. but it involved<br>
ceasing all use of the canvas's own scrolling/zoom mechanism, and setting<br>
up redraws in our own code.<br>
<br>
</blockquote></div>
It's entirely possible that I've misunderstood this (or maybe I'm looking in<br>
the wrong place) but that doesn't tie in with what I can see (at least, not<br>
in Ardour 2).  Scrolling the canvas in 'moving timeline' mode appears to be<br>
accomplished by programmatically 'repositioning' its horizontal scrollbar<br>
and letting gtk do the work.  </blockquote><div><br>nope. we have the move the scrollbar, but that would conventionally been done so that the GtkAdjustment connected to the scrollbar was changed. And then, when the adjustment changed, the canvas gets notified and repositions itself. at this point in time, the canvas no longer pays any attenton to the adjustment<br>
 <br>editor_canvas.cc contains Editor::scroll_canvas_horizontally() - you will find that we change the scrollbar (for appearance sake) and then "manually" move each part of the canvas as needed.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Unless Nick's changes were done a long time<br>
ago (or after version 2.7.1) that seems to have been the mechanism for a<br>
very long time (at least dating back to Ardour 2.4)..<br>
<br>
I'd love to be proved wrong but from what I've observed, around 90 percent<br>
of Ardour's work is being done in a single thread - and the more work that<br>
gets added to that thread, the slower it gets.  </blockquote><div><br>the GUI thread is not using very much CPU, and we'd have to add a lot more to it before it would be overloaded.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 But at this point in time - and expecially, given the evidence that<br>
the problem has crept up slowly and progressively </blockquote><div><br>there's no evidence of this john. you might be the only person on the planet who is using the stationary playhead mode, certainly with any recent versions of ardour. the problem could easily have started with a single commit.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- I'd be surprised if it's<br>
anything more complicated than an overworked thread.</blockquote><div><br>an overworked thread implies that a CPU monitor (and i cannot believe that you have been unable to find this on your system) would show the CPU maxxed out.<br>
<br> </div></div><br>