Actually the user needs to update to Beta3, since I did not fix the issue until Apr 29. (Reporting crashes without the build or version is a recurring problem it seems, ditto for reports without the OS info)
With respect to repaint/RepaintEvent... repaint _was_ being called by the end of the bpm detect thread, paintEvent is called by the UI thread whenever the UI is in need of an update. When the two used to try to update the same canvas at once magical crashing would happen (Xlib client, Qpainters, etc) I changed things so that a flag (waveformChanged) is set when the BPM detect routine finishes, then the next call to paintEvent by the UI thread will call repaint and reset the flag to false. The assumption is that there will only be one UI thread calling paintEvent, so there would be no need for a Mutex. -G On 6/4/08, Albert Santoni <[EMAIL PROTECTED]> wrote: > Garth, I think there needs to be some mutex locking around the QPainter > usage in woverview.cpp. It looks like we do something similar (to using > a mutex like this) in wvisualwaveform.cpp:247. > > Also, do you have any idea why there's separate painting code in > paintEvent() and repaint() in woverview.cpp? > > ** Changed in: mixxx > Importance: Undecided => High > Assignee: (unassigned) => ironstorm (ironstorm-gmail) > Status: New => Triaged > > -- > Mixxx crashed abruptedly > https://bugs.launchpad.net/bugs/237324 > You received this bug notification because you are a bug assignee. > -- Sent from Gmail for mobile | mobile.google.com __ --- == __/ t.O ==-- http://stacktrace.org/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
