traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Traverso-devel] playhead cpu usage, crosshair like implementation n


From: Remon
Subject: Re: [Traverso-devel] playhead cpu usage, crosshair like implementation needed ?
Date: Wed, 7 Feb 2007 21:14:30 +0100
User-agent: KMail/1.9.6

Hi,

Thanks for the explanation, I think I get the idea, and it might as well a 
solution for traverso to do more 'cached painting'.
It's doing this allready for expensive parts to paint.

The triple buffer for the playhead doesn't buffer the playhead, but the parts 
beneath it, it's conceptually different, most likely due traverso painting 
done with another approach :-)

Right now, I'm gonna say: "NANANANANAAAAA" to everone not owning a dual core 
2+ GHz computer :D

Greetings,

Remon

P.S.
And as soon as we get opengl accelerated painting, by means of new mesa and 
xorg versions, live is good again, and we get this acceleration for free, not 
a single line of code needed!

> > So, what you do is painting on something like an offscreen 'pixmap', and
> > paint the parts that are exposed from these pixmaps to the screen ?
>
> Yes, but it's not real pixmaps but cairo surfaces. One can do lots with
> cairo surfaces, combining them in different ways, using them as source
> patterns to fill other shapes with, transparency, etc...
>
> > That of course works, but e.g. when audioclips are very large, how do you
> > gonna know which part to paint on the pixmap?
>
> I draw only the part of the curves which I know is visible: starting at
> current horizontal scroll position and ending at that plus the window
> width. So when the visible part of the curve changes (the user edits the
> curve, or zooms or scrolls) then it's redrawn to the offscreen surface.
>
> > What bothers me a little with this approach, all these offscreen pixmaps
> > gonna consume tons of memory.. ?
>
> Not really. Each curve has a surface that is only as large as that
> curves visible part on screen.
>
> > If I understand you correctly, this indeed works, but means a true triple
> > buffering approach ?
> >
> > My proposed solution would only triple buffer the playhead canvas
> > item....
>
> It sounds really overkill to triplebuffer a simple vertical straight
> line! =)
> The thing is, if you have all other things ready-drawn in buffers, you
> don't need to redraw them, only repaint them. (where the difference is
> that redrawing is going through the process of how to render something
> to graphics, and painting is putting this graphics on the screen)
>
> > Oh well, after some cleanups the canvas painting has halved in cpu usage,
> > and Nicola's ppc can keep up with it nicely now, so I would say, let's
> > not spend to much time into this :-)
> > (CPU usage during playback on my pc == 0.5 % cpu usage, no big deal lol,
> > animated flip page ~ 10- 15 %)
>
> Sure, 0.5% is not even a small deal! =)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]