Yes. My only experience with this code is implementing the colour schemes, which you'll note don't quite work properly at the moment :)
On 26/11/2007, Albert Santoni <[EMAIL PROTECTED]> wrote: > On Mon, 2007-11-26 at 17:09 +0000, Adam Davison wrote: > > > I wrote something similar for Blender. It's an audio analysis tool > > > that graphs the contents of an entire wav file in a little window. > > > Granted making something generic enough to work with all media streams > > > would be a lot more challenging. Either way, I think the word > > > excessive does apply. Pixels on a canvas to reflect a waveform does > > > not really need the power of OpenGL. > > > > This just reminded me of the other important point here - Back in 2001, > I don't think QT had fast enough pixmap painting abilities in order to > do the waveform rendering. OpenGL is a simple cross-platform API that > allowed Tue to solve this problem without having to drag in a heavier > graphics library like SDL. There also used to be a "fish-eye" view that > could be enabled on the waveform, which involved a decent number of > matrix transformations. OpenGL lends itself nicely to this sort of > thing. However, the QT 4 canvas today is probably fast enough to do > waveform rendering at 60 fps (I'm basing that on nothing), and so I'd > encourage anyone who feels like rewriting the waveform view from scratch > in the future to look at all the possible options (and do some > benchmarking first). > > Oh, and the irony of all of this is that Blender uses OpenGL to draw > it's entire GUI, including your Audio Analysis tool. :) > > Lastly, I'd like to remind you that nobody on mixxx-devel is the > original author the waveform view, and that's why Adam and I are so > speculative about it's history and performance. It's also one of these > "black-box" parts of Mixxx that nobody understands very well. I've > debugged a few problems with it and patched it a few times, but that's > the extent of my history with it. (In fact, if Karlis is reading this, > he probably knows more about how it works than I do.) > :) > > Albert > > > I wouldn't be too hasty about this. Remember that overall latency (ie > > what the user cares about) includes the response time of the user > > interface. If you're dragging the waveform then you need to see it > > respond to what you're doing as quickly as possible for it to be a > > useful control method. We're essentially limited here by the refresh > > rate of your screen at 10-15ms latency. But we want to be as close to > > that as possible. > > > > The whole waveform has to be repainted every frame while using as > > little cpu time as possible so that we can give audio priority and > > keep latency low. Although a pure rough numbers calculation would > > imply that we could paint that number of pixels 60x a second without > > hardware accelleration reasonably easily you have to remember that > > user interface toolkits are not usually optimized for this kind of > > every frame drawing and there are usually additional buffering and > > compositing stages along the way. Using GL guarantees that we're > > always drawing pretty much as efficiently as the hardware allows. > > > > I agree that many modern machines can probably get by without it but > > for most people I suspect there will be a cost in latency. > > > > Having said that I have no numbers to back this up so if people want > > to try things I'm happy to evaluate them on their merits. I just want > > to make a point that there's more to this than meets the eye. > > > > Adam > > > > PS Here are some rough numbers, > > > > 100x1000 = 100,000 pixels > > 60fps => 6,000,000 px/s > > > > So for a 1Ghz processor: > > > > Ops/px Load > > 10 0.06 > > 100 0.6 > > 1000 6.0 > > > > So you can't screw around too much with this texture if you want to do > > it at 60fps (bearing in mind that you have to generate the texture > > too). > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Mixxx-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
