| Summary: | MarbleWidget and Slider for the zoom causes the application to use 100% CPU. | ||
|---|---|---|---|
| Product: | [Applications] marble | Reporter: | Miguel Chavez Gamboa <miguel.chavez.gamboa> |
| Component: | general | Assignee: | marble-bugs |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | nienhueser |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | 1.0 (KDE 4.6) | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Just a quick guess (didn't look into it in detail yet): Does changeSlider(int) cause another map->zoomView() call? Then bug 249628 could be related, because there'd be a circular connection that's not broken in MarbleWidget because of the off-by-one error. (In reply to comment #1) > Just a quick guess (didn't look into it in detail yet): Does changeSlider(int) > cause another map->zoomView() call? Then bug 249628 could be related, because > there'd be a circular connection that's not broken in MarbleWidget because of > the off-by-one error. I also think its a endless loop, and maybe related to the bug 249628. I removed the animations, and before making the connection (signal->slot) of the slider, i call: slider->setValue(2000); theMap->zoomView(2000); .. connect( ..the signal connections.. ); And it works fine the first zoomView, after the signal connection, if i click the Zoom-in button, the zoom changes from 2000 to 1000 and the app freezes. I placed a qDebug() at the MarbleWidget::zoomView(...) and i got this: ZomView newZoom: 2039 ZomView newZoom: 2038 ZomView newZoom: 2037 ... More output ... ZomView newZoom: 1003 ZomView newZoom: 1002 ZomView newZoom: 1000 ..here it freezes. (In reply to comment #1) > Just a quick guess (didn't look into it in detail yet): Does changeSlider(int) > cause another map->zoomView() call? Then bug 249628 could be related, because > there'd be a circular connection that's not broken in MarbleWidget because of > the off-by-one error. I think its what you say, a circular signals-slot reactions (the slider changes and the map zoom changes in reaction, then as the map zoom changed the slider changes again and the loop is endless) I can see this if I remove the connect(ui->zoomSlider, SIGNAL(valueChanged(int)), theMap, SLOT(zoomView(int)) ); but keep the connect(theMap, SIGNAL(zoomChanged(int)), ui->zoomSlider, SLOT(setValue(int)) ); I does not freezes. This way I can get the slider updated when the marblewidget's zoom changes, but I cannot zoom with the slider. SVN commit 1185567 by nienhueser: Round, don't cut. BUG: 249628 CCBUG: 254000 M +1 -1 MarbleMap.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1185567 The implementation of our own slider has some interesting notes on this btw. Also notice the blockSignals() calls.
// There exists a circular signal/slot connection between MarbleWidget and this widget's
// zoom slider. MarbleWidget prevents recursion, but it still loops one time unless
// blocked here. Note that it would be possible to only connect the sliders
// sliderMoved signal instead of its valueChanged signal above to break up the loop.
// This however means that the slider cannot be operated with the mouse wheel, as this
// does not emit the sliderMoved signal for some reason. Therefore the signal is blocked
// below before calling setValue on the slider to avoid that it calls back to MarbleWidget,
// and then un-blocked again to make user interaction possible.
d->m_navigationUi.zoomSlider->blockSignals( true );
d->m_navigationUi.zoomSlider->setValue( zoom );
d->m_navigationUi.zoomSlider->setMinimum( minimumZoom() );
// As we have disabled all zoomSlider Signals, we have to update our buttons seperately.
updateButtons( zoom );
d->m_navigationUi.zoomSlider->blockSignals( false );
Ok, that works. As is not a marble bug, but mine, i will close it. Thanks! |
Version: unspecified (using Devel) OS: Linux Using marble (library) from SVN (revision r1184939) in my application. My application is doing a programatically zoom in to an area (animated) at the begining. Placing a slider bar for controling the zoom in/out, and making the connections for syncing both widgets, specially the next connection is causing the problem: connect(theMap, SIGNAL(zoomChanged(int)), this, SLOT(changeSlider(int)) ); Instead of directly connecting the signal to the setValue()slot of the Slider, I used a intermediary slot (changeSlider), and i noted that the ui->zoomSlider->setValue(x); code is what is causing the app to freeze for some moments (using 100% CPU) and repeated times. The code was working for some days without the freeze, but at some point i did some updates (ubuntu, and marble's code from svn) and it appeared. Reproducible: Didn't try Steps to Reproduce: described above Im not sure if the bug/problem is marble related or qt related, because the problem happens with qt code (slider->setValue()). If I filter the number of times the slider->setValue() is executed, the problem minimizes but it does not disappears: void MainWindow::changeSlider(int x) { if ((x>1000 && x<1005) || (x>2397)) ui->zoomSlider->setValue(x); }