[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Re: [Traverso-devel] playhead cpu usage, crosshair like implementa
From: |
Remon |
Subject: |
Fwd: Re: [Traverso-devel] playhead cpu usage, crosshair like implementation needed ? |
Date: |
Tue, 6 Feb 2007 13:56:42 +0100 |
User-agent: |
KMail/1.9.6 |
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
-------------------------------------------------------
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Fwd: Re: [Traverso-devel] playhead cpu usage, crosshair like implementation needed ?,
Remon <=