Fwd: Re: [Traverso-devel] playhead cpu usage, crosshair like implementation needed ?

[Remon]

Oops, mailinglist reply problem again. Please use L when replying to 
mailinglists messages ;-)
(Maybe we all should go back to mutt, that one knows how to reply properly 
lol)

Hi,

> > My idea was, with the above scenario, to first create a copy of the
> > canvas at the old position of the playhead, of course only the
> > region that it covers, and restore it before it moves. Making a
> > copy of a Pixmap and drawing it back is much cheaper then drawing
> > all the items underneath the playhead!!
>
> you mean something like tripple-buffering (since qt4 does double
> buffering on its own)?

To a degree, yes, that would be tripple-buffering, but only for the region 
that are covered by the playhead.

> i thought scrolling for qt4 would be quite efficient in that way. as
> far as i remember

It is actually very efficient, scrolling only paints the newly exposed area, 
and copies the non-damaged (I hope that the correct word) part of the 
backingstore to the new position. (i.e. moves the content of the backingstore 
by a dx, dy amount)

> the original qcanvas stuff supported layers, so in that way the cursor
> could be put into
> a layer above the waveforms etc. i dunno if qgraphics has that as
> well, but that would
> be probably the most efficient way. (i am sorry i didnt look at your
> implementation).

QGraphicsView displays (part of a) scene which is populated with 
qgraphicsitems.
The playhead is an item like all the others, but with sufficiently high Z 
value, to always stay on top.

> i think there are numberous ways of accomplishing that, i would have
> to look at your code
> and again at the qgraphicsview-api.
> gotta look into all that the next week.

Would be great, it seems something so simple and obvious, but somehow I fail 
to see a solution, without sacrificing the Qt backingstore, and flexability 
the QGraphicsView gives me.

The paintengine of Qt 4 is vector based, so almost all paint operations 
(except drawing lines) as done be painting polygons.
This means that the tesselator has to be fast, since there's were most of the 
cpu time will be spend. 
Qt 4.3 has a MUCH improved tesselator, and my last observation using Qt 4.3 
snapshot is that cpu load has reduced to almost 0 while painting the playhead 
(during playback) when it's moving with a speed that's easy to follow with 
the eyes.
Strange thing that happens: when the screen size is higher ~ 500 pixels, xorg 
load jumps to ~ 15% (on my core2 duo 2Ghz proc)

Oh well, if a simple non intrusive triple buffering approach can be made for 
painting the playhead, I'm all in for it, if it can't be made, then we have 
to wait a bit for Qt 4.3 and a xorg that uses the real power of your graphics 
card :-)

Greetings,

Remon

-------------------------------------------------------