FYI... Here is the start of our repaint() method:
108 void WOverview::repaint() {
109 if (!m_pWaveformSummary || !m_pWaveformSummary->size())
110 return;
111
112 QPainter paint;
113 paint.begin(m_pScreenBuffer, this);
114
115 // Erase background
116 paint.eraseRect(rect());
117
118 float yscale = (((float)(height()-2)/2.)/128.); //32768.;
119 float xscale = (float)m_pWaveformSummary->size()/width();
The block from the bottom of this posting looks promising:
http://lists.trolltech.com/qt-interest/2005-03/thread00136-0.html#msg00182
QWaitCondition renderingDone;
>
> // thread which rotates the model, even if user doesn't interact
> // with the mouse
> MyQGLWidget::run()
> {
>
> ...
> updateScene(); // rotate, translate etc
> // inform the GUI thread that this widget needs to be
> // repainted
> qApp->postEvent (this,
> new QPaintEvent(QRegion (QRect (this->rect())),
> false));
> ...
> // wait until previous rendering has finished
> renderingDone.wait();
> }
>
> void MyQGLWidget::paintEvent (QPaintEvent *pe) {
>
> QGLWidget::paintEvent (pe);
>
> ...
> if (doRotate == true) {
> // inform the thread to render the next frame
> renderingDone.wakeOne();
> }
> ...
> }
>
>
Guess we could put the post event in setData() instead of the call
repaint(), then rename repaint to paintEvent.... or something...
On Mon, Apr 28, 2008 at 2:05 AM, Garth Dahlstrom <[EMAIL PROTECTED]>
wrote:
> I get hit by XLib errors every so often... They seem to occur during
> track loads and they lock up the UI thread.
>
> Decided to take a poke around in the code after looking at this post:
> http://lists.trolltech.com/qt-interest/2005-05/msg00702.html
>
> Here's what I found:
>
> Around line #155 of wavesummary.cpp we call:
> pTrackInfoObject->setWaveSummary(pData, 0);
>
> If I comment out this line, I can load tracks very aggressively and I
> don't get XLib errors. (of course, I don't get wave summarys either)
>
> setWaveSummary is defined here:
>
> 851 void TrackInfoObject::setWaveSummary(Q3MemArray<char> * pWave,
> Q3ValueList<long> * pSegmentation)
> 852 {
> 853 m_qMutex.lock();
> 854 m_pWave = pWave;
> 855 m_pSegmentation = pSegmentation;
> 856 m_qMutex.unlock();
> 857
> 858 setOverviewWidget(m_pOverviewWidget);
> 859 }
>
> It calls
>
> 875 void TrackInfoObject::setOverviewWidget(WOverview * p)
> 876 {
> 877 m_pOverviewWidget = p;
> 878
> 879 if (m_pOverviewWidget)
> 880 p->setData(getWaveSummary(), getSegmentationSummary(),
> getDuration()*getSampleRate()*getChannels());
> 881 }
>
> That calls:
>
> 99 void WOverview::setData(Q3MemArray<char> * pWaveformSummary,
> Q3ValueList<long> * pSegmentation, long liSampleDuration)
> 100 {
> 101 m_pWaveformSummary = pWaveformSummary;
> 102 m_pSegmentation = pSegmentation;
> 103 m_liSampleDuration = liSampleDuration;
> 104
> 105 repaint();
> 106 }
>
> So to me it looks like the wave summary thread is making a call to paint
> the widget directly, something the mailing list post suggests is a bad idea
> to do outside the main UI thread...
>
> Now, I have to read a bit more about sending QEvents around...
>
> --
> __
> --- == __/ t.O ==--
> http://stacktrace.org/
--
__
--- == __/ t.O ==--
http://stacktrace.org/
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
