> 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. (?)
Ok cool. > 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. So it's not just limited to Linux. That implies it's a Qt problem rather than drivers. Fair enough, sounds reasonable then. Might be worth feeding some of this back to the Qt people as we're probably one of a small number of people doing non-trivial stuff and deploying it on 3 operating systems. Adam > > 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
