<br><br><div class="gmail_quote">On Sun, Mar 8, 2009 at 7:07 AM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@kokkinizita.net">fons@kokkinizita.net</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;">
<div class="im"><br>
</div>It shouldn't be a CPU hog. Yass (scrolling scope) running<br>
full-screen, 100 updates/second, </blockquote><div><br>how does it accomplish this on an 80Hz monitor?<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;">

You need to repaint only two narrow vertical strips,<br>
the new part at the right, and the one that was covered<br>
by the playhead in it previous position. The important<br>
part is to structure your display code in such a way<br>
it can do this efficiently.<br></blockquote><div><br>the problem is that its not always "your" display code that is the problem. we reworked the canvas display logic to avoid a very nasty problem with X & the GnomeCanvas. the Canvas has no concept of "zoom, keeping the center of the current display in the center". to make that happen with "naive" Canvas code you end up with a window move and then a redraw (move to reposition so that when the redraw is done, the correct part of the window is visible. because X is async, you can sometimes (often!) see the intermediate state between the window move and the redraw. nick redesigned how things happen so that this problem is completely avoided (basically, never using Canvas scrolling) but it would not suprise me if this has broken the "stationary PH option" which explicitly scrolled the entire canvas window. note that this behaviour does not occur on OS X where their windowing architecture is so explicitly double-buffered that its impossible to see "intermediate" states (well, nothing is impossible, but ...)<br>
<br>there is no question of us going back to the old scrolling stuff - it led to absolutely horrible visual results when zooming with anything except the left edge of the screen as the zoom "anchor" point. the real future here is in a new canvas entirely, and although once that seemed as though it would certainly be a part of the ardour 3.0 development path, but that is not the case and i honestly do not when it might happen. it does need to though, for a variety of other reasons as well as this one.<br>
 </div></div><br>