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
