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

[Fons Adriaensen]

On Sat, Mar 07, 2009 at 10:21:58PM -0600, David Taht wrote:

> > there is no point in ever trying to do screen updates faster than the
> > monitor refresh rate, which is typically 60-80Hz. it was reduced to 80 and
> > then 40 because in reality, film projection at 30FPS is indistinguishable to
> > the human eye from continuous motion. the honest truth is that it could
> > probably drop to 20 before anyone would even notice.
> 
> I am going to disagree with this slightly. If you are doing different
> kinds of updates to the screen it helps to be sending the draw commands
> as fast as possible, so that the display hardware has smaller chunks to

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.

Higher level canvas code should provide access to it
in some way, if not you have to bypass some levels of
abstraction (work out the geometry, not a big deal)
and use the X11 or OSX call directly.

You need to repaint only two narrow vertical strips,
the new part at the right, and the one that was covered
by the playhead in it previous position. The important
part is to structure your display code in such a way
it can do this efficiently.

Ciao,

-- 
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Be quiet, Master Land; and you, Professor,
will you be so good as to listen to me ?