Thanks for the data Sean. Replies to Adam inline below:
On Tue, Apr 6, 2010 at 4:41 AM, Adam Davison <[email protected]> wrote: > This scares me a tiny bit and I wouldn't mind understanding why this works :) > > So you're still using opengl to do the offscreen render of the > waveform originally? If so then this doesn't mean we can do without gl > per-se. > No, we're not using OpenGL to do the offscreen render in this case. It's using the QPainter API which is likely just using X to draw onto the pixmaps. (?) > I can think of a few possible explanations... > > 1. Like Sean said all the load has gone into the X.org thread :) > 2. Qt/X is using OpenGL to do the blitting anyway behind the scenes > and doing it better than we did (power-of-two buffers, power-of-two > textures, knows about driver quirks etc...) > 3. Cosmic rays > > But all that aside if it works it's probably a good idea. Although it > might be technically inferior it seems like we've basically found that > the quality of linux graphics drivers is all around crap. So if we can > mitigate some of that and actually have it work for everyone then > that's a big improvement. Did we figure out in the end that all these > people with slow waveform were using any particular os or card? The waveform corruption problem is seen with tons of hardware/software configurations, but the common thing seems to be a compositing window manager, as far as I can tell. I tested another Qt application I wrote that uses multiple QGLWidgets and I have similar corruption. I'm not sure if it's Compiz, X, or some combination of the two that's the problem here, but there don't seem to be a whole lot of concrete bug reports about it on the net, so I'm not sure if the Compiz/X people are aware of it. On OS X, Jus has a Geforce 8 mobile or something similarly powerful. He saw performance problems due to the waveform when we upgraded from Qt 4.5 to 4.6. According to the Qt 4.6 changelog: "The default engine used to draw onto OpenGL buffers has changed in Qt 4.6. The QPaintEngine::OpenGL2 engine is now used as the default engine. This *may* cause compatibility problems for applications that use a mix of QPainter and native OpenGL calls to draw into a GL buffer. Use the QGL::setPreferredPaintEngine() function to enforce usage of the old GL paint engine." http://qt.gitorious.org/qt/qt/blobs/512a265f760c9207b94d7ba61cef9316b23cf4e8/dist/changes-4.6.0 I guess the old one was QPaintEngine::OpenGL, and the new one is just buggy and slow, for whatever reason. Maybe we should just set our waveform paint engine back to QPaintEngine::OpenGL for 1.8... Thanks, Albert > > On 6 April 2010 11:47, Sean M. Pappalardo - D.J. Pegasus > <[email protected]> wrote: >> On this single-core Athlon XP-M 1.6GHz with nVidia GeForce 4 Go on >> Debian Squeeze, I see an effective CPU usage reduction of about half >> with this branch+patch (Mixxx ~40%) compared to current trunk (~80%.) >> However, it doesn't seem to affect the latency I can achieve, and the >> XOrg process' CPU usage is increased a bit (from ~8% on trunk to ~15% on >> this.) >> >> Sean >> D.J. Pegasus >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Mixxx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel >> > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
