Version: 1.1.0_devel (using KDE 3.2 BRANCH >= 20040204, Mandrake Linux Cooker i586 - Cooker) Compiler: gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) OS: Linux (i686) release 2.6.3-7mdk I have installed 3 different kst versions in parallel to perform comparisons (installed using different --prefix values at configure time and corresponding KDEDIRS combinations like /usr/local/kst-V1:/usr or /usr/local/kst-V2:/usr). I have just played around a lot with them to try and narrow down the curve painting problems I have just reported, and I can confirm my first impressions : changing curve attributes has become slower by a factor 10 or 50 !!! I am comparing a Nov. 6th snapshot, 1.0.0 and today's cvs version. Here is what I notice: 1. in 1.0.0, the dialog hangs around for a while, and the drawing is delayed 2. in cvs, the dialog closes quickly but curve drawing is delayed 3. in the snapshot, the drawing starts imediately and seems instantaneous (if the curve is not 200 000 samples of course) while the dialog sometimes still hangs around for a while. Desired behavior would of course be for the drawing to happen immediately as the dialog to get out of the way as soon as OK is clicked.
CVS commit by staikos: make forced updates happen immediately This is as close as we'll get to fixing 95025 without fixing 95117 I think. It still pauses after the dialog closes, but this is because it's doing an update before it repaints. BUG: 95025 M +10 -2 updatethread.cpp 1.37 --- kdeextragear-2/kst/kst/updatethread.cpp #1.36:1.37 @@ -59,6 +59,8 @@ void UpdateThread::run() { kdDebug() << "Update timer" << _updateTime << endl; #endif + if (!_force) { break; } + } _statusMutex.lock(); @@ -289,4 +291,5 @@ void UpdateThread::setFinished(bool fini _statusMutex.lock(); _done = finished; + _force = false; _statusMutex.unlock(); _waitCondition.wakeOne(); @@ -295,6 +298,11 @@ void UpdateThread::setFinished(bool fini void UpdateThread::forceUpdate() { - QMutexLocker ml(&_statusMutex); + if (_done) { + return; + } + _statusMutex.lock(); _force = true; + _statusMutex.unlock(); + _waitCondition.wakeOne(); }