[Ardour-Dev] SuperRapidScreenUpdates are neither rapid, nor super.

[John Emmas]

----- Original Message -----
From: "Fons Adriaensen"
Subject: Re: [Ardour-Dev] SuperRapidScreenUpdates are neither rapid,nor
super.
>
> It shouldn't be a CPU hog. Yass (scrolling scope) running
> full-screen, 100 updates/second, 24 tracks and a zoom
> level already to high to be useful generates 3% (total
> CPU load) on my seven year old hardware.
>
> Ardour's display has a bit more eye candy, but not to
> the point it should take more than double this figure.
>
> Most of the window just can be moved and does not need
> be to be repainted. At least X11 has a call to do this
> that will be HW accelerated by almost all drivers. I'm
> sure that the native OSX framework has something similar.
>
I'm inclined to agree that lack of processing power isn't likely to be the
explanation although I've yet to get any hard figures.  However I can
reproduce the same results and timings on 2 different PC's (one running at
1.2GHz and the other at 1.8GHz) and I know that at least one other user is
experiencing the same problem on different hardware again.

Paul might correct me here but AFAICT Ardour itself has little to do with
canvas scrolling.  The strategy that seems to be employed is that the canvas
gets scrolled by making small incremental changes to its horizontal scroll
bar - we then rely on gtk to do the actual work, so I guess we're stuck with
(or blessed by) whatever strategy is used by gtk.  The problem in this case
is that those incremental changes are happening much less frequently than
they were designed to (and are therefore more 'grainy' when they do happen).

I'm hoping to get some figures on CPU usage by the end of today but in their
absence, there's pretty strong evidence to suggest that the main UI thread
is simply being overloaded with work.  On my system, the last svn revision
where this worked reasonably smoothly (24 updates/sec) was svn 3695.  But we
know that at one point in the past, there were upwards of 40 updates/sec.
By svn 4619 this was down to around 5 updates/sec - so this morning I
decided to arbitrarily install svn 4000 and measure its refresh rate.  I was
hoping that it would either be 5 or 24 but I was disappointed - in fact, it
came out at 15 updates/second.

So, rather than being caused by a sudden change, the evidence seems to
suggest that the UI thread is slowly but surely grinding to a halt.

I guess this is going to make it a difficult problem to solve....  :-(

John