Very slow context menu invocation
Locked
Very slow context menu invocation
 
|
Hi,
since a few weeks the context menu is generated very slow, especially when called for the first time. I now found the bottleneck: Digikam::ImageCurves::fillFromOtherCurves() at imagecurves.cpp:149 0xb6fd896e Digikam::CurvesWidget::updateData() at curveswidget.cpp:477 0xb6fdecca Digikam::CurvesWidget::CurvesWidget() at curveswidget.cpp:347 0xb6fde06f Digikam::CurvesBox::CurvesBox() at curvesbox.cpp:112 0xb6fe221a Digikam::BWSepiaSettings::BWSepiaSettings() at bwsepiasettings.cpp:361 0xb6f9c8eb Digikam::BWConvert::BWConvert() at bwconvert.cpp:53 0x82a0053 Digikam::BatchToolsManager::BatchToolsManager() at batchtoolsmanager.cpp:116 0x82932a6 Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 0x827d80a Digikam::QueueMgrWindow::queueManagerWindow() at queuemgrwindow.cpp:106 0x827d24b Digikam::ContextMenuHelper::addQueueManagerMenu() at contextmenuhelper.cpp:741 0x81b096a Digikam::DigikamImageView::showContextMenuOnInfo() at digikamimageview.cpp:222 0x81d3a92 We call this instruction chain whenever the context menu is openend. But why? Wouldn't it be enough to just generate the QueueMgrWindow without all this stuff? Especially when no images have been added to the BQM? Andi _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
Beacuse context menu query BQM to know if a queue is ready to host item.
When you just start digiKam , BQM instance is not yet in memory call context menu initiate BQM and especially all BQM tools. This is take a while. I dicovered this under mac, with blur algorithm crash. The solution is to initiate BQM tool when BQM windows is open. Gilles Caulier 2010/11/28 Andi Clemens <[hidden email]>: > Hi, > > since a few weeks the context menu is generated very slow, especially when > called for the first time. > I now found the bottleneck: > > Digikam::ImageCurves::fillFromOtherCurves() at imagecurves.cpp:149 0xb6fd896e > Digikam::CurvesWidget::updateData() at curveswidget.cpp:477 0xb6fdecca > Digikam::CurvesWidget::CurvesWidget() at curveswidget.cpp:347 0xb6fde06f > Digikam::CurvesBox::CurvesBox() at curvesbox.cpp:112 0xb6fe221a > Digikam::BWSepiaSettings::BWSepiaSettings() at bwsepiasettings.cpp:361 > 0xb6f9c8eb > Digikam::BWConvert::BWConvert() at bwconvert.cpp:53 0x82a0053 > Digikam::BatchToolsManager::BatchToolsManager() at batchtoolsmanager.cpp:116 > 0x82932a6 > Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 0x827d80a > Digikam::QueueMgrWindow::queueManagerWindow() at queuemgrwindow.cpp:106 > 0x827d24b > Digikam::ContextMenuHelper::addQueueManagerMenu() at contextmenuhelper.cpp:741 > 0x81b096a > Digikam::DigikamImageView::showContextMenuOnInfo() at digikamimageview.cpp:222 > 0x81d3a92 > > We call this instruction chain whenever the context menu is openend. > But why? Wouldn't it be enough to just generate the QueueMgrWindow without all > this stuff? Especially when no images have been added to the BQM? > > > Andi > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
In reply to this post by Bugzilla from andi.clemens@gmx.net
> Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 > 0x827d80a Digikam::QueueMgrWindow::queueManagerWindow() at > queuemgrwindow.cpp:106 0x827d24b > Digikam::ContextMenuHelper::addQueueManagerMenu() at > contextmenuhelper.cpp:741 0x81b096a > Digikam::DigikamImageView::showContextMenuOnInfo() at > digikamimageview.cpp:222 0x81d3a92 > > We call this instruction chain whenever the context menu is openend. > But why? Wouldn't it be enough to just generate the QueueMgrWindow without > all this stuff? Especially when no images have been added to the BQM? If the QueueManagerWindow is supposed to be a singleton, like the ImageWindow, there should be an additional method which returns the singleton pointer (or a bool) but does not create it. With K_GLOBAL_STATIC, there is a method exists() on the creator _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
Marcel,
This method already exist : class QueueMgrWindow : public KXmlGuiWindow { Q_OBJECT public: ~QueueMgrWindow(); static QueueMgrWindow* queueManagerWindow(); static bool queueManagerWindowCreated(); ... So it can be used in ContextMenuHelper... Gilles 2010/11/28 Marcel Wiesweg <[hidden email]>: > >> Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 >> 0x827d80a Digikam::QueueMgrWindow::queueManagerWindow() at >> queuemgrwindow.cpp:106 0x827d24b >> Digikam::ContextMenuHelper::addQueueManagerMenu() at >> contextmenuhelper.cpp:741 0x81b096a >> Digikam::DigikamImageView::showContextMenuOnInfo() at >> digikamimageview.cpp:222 0x81d3a92 >> >> We call this instruction chain whenever the context menu is openend. >> But why? Wouldn't it be enough to just generate the QueueMgrWindow without >> all this stuff? Especially when no images have been added to the BQM? > > If the QueueManagerWindow is supposed to be a singleton, like the ImageWindow, > there should be an additional method which returns the singleton pointer (or a > bool) but does not create it. With K_GLOBAL_STATIC, there is a method exists() > on the creator > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
Well it is used, the problem is that the BQM window initializes all of its
plugins, even though there are not used / assigned at this moment. Maybe we can initialize plugins only when they are assigned? Andi Clemens ----------------- www.digikam.org On Tuesday 30 November 2010 22:05:07 Gilles Caulier wrote: > Marcel, > > This method already exist : > > class QueueMgrWindow : public KXmlGuiWindow > { > Q_OBJECT > > public: > > ~QueueMgrWindow(); > > static QueueMgrWindow* queueManagerWindow(); > static bool queueManagerWindowCreated(); > > ... > > So it can be used in ContextMenuHelper... > > Gilles > > 2010/11/28 Marcel Wiesweg <[hidden email]>: > >> Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 > >> 0x827d80a Digikam::QueueMgrWindow::queueManagerWindow() at > >> queuemgrwindow.cpp:106 0x827d24b > >> Digikam::ContextMenuHelper::addQueueManagerMenu() at > >> contextmenuhelper.cpp:741 0x81b096a > >> Digikam::DigikamImageView::showContextMenuOnInfo() at > >> digikamimageview.cpp:222 0x81d3a92 > >> > >> We call this instruction chain whenever the context menu is openend. > >> But why? Wouldn't it be enough to just generate the QueueMgrWindow > >> without all this stuff? Especially when no images have been added to > >> the BQM? > > > > If the QueueManagerWindow is supposed to be a singleton, like the > > ImageWindow, there should be an additional method which returns the > > singleton pointer (or a bool) but does not create it. With > > K_GLOBAL_STATIC, there is a method exists() on the creator > > _______________________________________________ > > Digikam-devel mailing list > > [hidden email] > > https://mail.kde.org/mailman/listinfo/digikam-devel > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
2010/11/30 Andi Clemens <[hidden email]>:
> Well it is used, the problem is that the BQM window initializes all of its > plugins, even though there are not used / assigned at this moment. > > Maybe we can initialize plugins only when they are assigned? Not when they have assigned, but when BQM main windows is displayed at the first time. Typically, All tools instance are created by BatchToolsManager class This manager is created in QueueMgrWindow constructor, as a lots of other classes, as ActionThread, which can be created only when BQM window is displayed at the first time on screen... Gilles > > > Andi Clemens > ----------------- > www.digikam.org > > On Tuesday 30 November 2010 22:05:07 Gilles Caulier wrote: >> Marcel, >> >> This method already exist : >> >> class QueueMgrWindow : public KXmlGuiWindow >> { >> Q_OBJECT >> >> public: >> >> ~QueueMgrWindow(); >> >> static QueueMgrWindow* queueManagerWindow(); >> static bool queueManagerWindowCreated(); >> >> ... >> >> So it can be used in ContextMenuHelper... >> >> Gilles >> >> 2010/11/28 Marcel Wiesweg <[hidden email]>: >> >> Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 >> >> 0x827d80a Digikam::QueueMgrWindow::queueManagerWindow() at >> >> queuemgrwindow.cpp:106 0x827d24b >> >> Digikam::ContextMenuHelper::addQueueManagerMenu() at >> >> contextmenuhelper.cpp:741 0x81b096a >> >> Digikam::DigikamImageView::showContextMenuOnInfo() at >> >> digikamimageview.cpp:222 0x81d3a92 >> >> >> >> We call this instruction chain whenever the context menu is openend. >> >> But why? Wouldn't it be enough to just generate the QueueMgrWindow >> >> without all this stuff? Especially when no images have been added to >> >> the BQM? >> > >> > If the QueueManagerWindow is supposed to be a singleton, like the >> > ImageWindow, there should be an additional method which returns the >> > singleton pointer (or a bool) but does not create it. With >> > K_GLOBAL_STATIC, there is a method exists() on the creator >> > _______________________________________________ >> > Digikam-devel mailing list >> > [hidden email] >> > https://mail.kde.org/mailman/listinfo/digikam-devel >> >> _______________________________________________ >> Digikam-devel mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-devel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
Fixed. Try with my commit #1202606
Gilles 2010/11/30 Gilles Caulier <[hidden email]>: > 2010/11/30 Andi Clemens <[hidden email]>: >> Well it is used, the problem is that the BQM window initializes all of its >> plugins, even though there are not used / assigned at this moment. >> >> Maybe we can initialize plugins only when they are assigned? > > Not when they have assigned, but when BQM main windows is displayed at > the first time. > > Typically, All tools instance are created by BatchToolsManager class > > This manager is created in QueueMgrWindow constructor, as a lots of > other classes, as ActionThread, which can be created only when BQM > window is displayed at the first time on screen... > > Gilles > >> >> >> Andi Clemens >> ----------------- >> www.digikam.org >> >> On Tuesday 30 November 2010 22:05:07 Gilles Caulier wrote: >>> Marcel, >>> >>> This method already exist : >>> >>> class QueueMgrWindow : public KXmlGuiWindow >>> { >>> Q_OBJECT >>> >>> public: >>> >>> ~QueueMgrWindow(); >>> >>> static QueueMgrWindow* queueManagerWindow(); >>> static bool queueManagerWindowCreated(); >>> >>> ... >>> >>> So it can be used in ContextMenuHelper... >>> >>> Gilles >>> >>> 2010/11/28 Marcel Wiesweg <[hidden email]>: >>> >> Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 >>> >> 0x827d80a Digikam::QueueMgrWindow::queueManagerWindow() at >>> >> queuemgrwindow.cpp:106 0x827d24b >>> >> Digikam::ContextMenuHelper::addQueueManagerMenu() at >>> >> contextmenuhelper.cpp:741 0x81b096a >>> >> Digikam::DigikamImageView::showContextMenuOnInfo() at >>> >> digikamimageview.cpp:222 0x81d3a92 >>> >> >>> >> We call this instruction chain whenever the context menu is openend. >>> >> But why? Wouldn't it be enough to just generate the QueueMgrWindow >>> >> without all this stuff? Especially when no images have been added to >>> >> the BQM? >>> > >>> > If the QueueManagerWindow is supposed to be a singleton, like the >>> > ImageWindow, there should be an additional method which returns the >>> > singleton pointer (or a bool) but does not create it. With >>> > K_GLOBAL_STATIC, there is a method exists() on the creator >>> > _______________________________________________ >>> > Digikam-devel mailing list >>> > [hidden email] >>> > https://mail.kde.org/mailman/listinfo/digikam-devel >>> >>> _______________________________________________ >>> Digikam-devel mailing list >>> [hidden email] >>> https://mail.kde.org/mailman/listinfo/digikam-devel >> _______________________________________________ >> Digikam-devel mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-devel >> > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
Several problems:
1. it doesn't compile 2. if named correctly, the ImageWindow::loadPlugins() method crashes => digiKam doesn't start Andi Clemens ----------------- www.digikam.org On Wednesday 01 December 2010 15:52:09 Gilles Caulier wrote: > Fixed. Try with my commit #1202606 > > Gilles > > 2010/11/30 Gilles Caulier <[hidden email]>: > > 2010/11/30 Andi Clemens <[hidden email]>: > >> Well it is used, the problem is that the BQM window initializes all of > >> its plugins, even though there are not used / assigned at this moment. > >> > >> Maybe we can initialize plugins only when they are assigned? > > > > Not when they have assigned, but when BQM main windows is displayed at > > the first time. > > > > Typically, All tools instance are created by BatchToolsManager class > > > > This manager is created in QueueMgrWindow constructor, as a lots of > > other classes, as ActionThread, which can be created only when BQM > > window is displayed at the first time on screen... > > > > Gilles > > > >> Andi Clemens > >> ----------------- > >> www.digikam.org > >> > >> On Tuesday 30 November 2010 22:05:07 Gilles Caulier wrote: > >>> Marcel, > >>> > >>> This method already exist : > >>> > >>> class QueueMgrWindow : public KXmlGuiWindow > >>> { > >>> Q_OBJECT > >>> > >>> public: > >>> > >>> ~QueueMgrWindow(); > >>> > >>> static QueueMgrWindow* queueManagerWindow(); > >>> static bool queueManagerWindowCreated(); > >>> > >>> ... > >>> > >>> So it can be used in ContextMenuHelper... > >>> > >>> Gilles > >>> > >>> 2010/11/28 Marcel Wiesweg <[hidden email]>: > >>> >> Digikam::QueueMgrWindow::QueueMgrWindow() at queuemgrwindow.cpp:137 > >>> >> 0x827d80a Digikam::QueueMgrWindow::queueManagerWindow() at > >>> >> queuemgrwindow.cpp:106 0x827d24b > >>> >> Digikam::ContextMenuHelper::addQueueManagerMenu() at > >>> >> contextmenuhelper.cpp:741 0x81b096a > >>> >> Digikam::DigikamImageView::showContextMenuOnInfo() at > >>> >> digikamimageview.cpp:222 0x81d3a92 > >>> >> > >>> >> We call this instruction chain whenever the context menu is openend. > >>> >> But why? Wouldn't it be enough to just generate the QueueMgrWindow > >>> >> without all this stuff? Especially when no images have been added to > >>> >> the BQM? > >>> > > >>> > If the QueueManagerWindow is supposed to be a singleton, like the > >>> > ImageWindow, there should be an additional method which returns the > >>> > singleton pointer (or a bool) but does not create it. With > >>> > K_GLOBAL_STATIC, there is a method exists() on the creator > >>> > _______________________________________________ > >>> > Digikam-devel mailing list > >>> > [hidden email] > >>> > https://mail.kde.org/mailman/listinfo/digikam-devel > >>> > >>> _______________________________________________ > >>> Digikam-devel mailing list > >>> [hidden email] > >>> https://mail.kde.org/mailman/listinfo/digikam-devel > >> > >> _______________________________________________ > >> Digikam-devel mailing list > >> [hidden email] > >> https://mail.kde.org/mailman/listinfo/digikam-devel > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: Very slow context menu invocation
|
|
Should be fixed now
Andi Clemens ----------------- www.digikam.org On Wednesday 01 December 2010 23:23:22 Andi Clemens wrote: > Several problems: > > 1. it doesn't compile > 2. if named correctly, the ImageWindow::loadPlugins() method crashes => > digiKam doesn't start > > Andi Clemens > ----------------- > www.digikam.org > > On Wednesday 01 December 2010 15:52:09 Gilles Caulier wrote: > > Fixed. Try with my commit #1202606 > > > > Gilles > > > > 2010/11/30 Gilles Caulier <[hidden email]>: > > > 2010/11/30 Andi Clemens <[hidden email]>: > > >> Well it is used, the problem is that the BQM window initializes all of > > >> its plugins, even though there are not used / assigned at this moment. > > >> > > >> Maybe we can initialize plugins only when they are assigned? > > > > > > Not when they have assigned, but when BQM main windows is displayed at > > > the first time. > > > > > > Typically, All tools instance are created by BatchToolsManager class > > > > > > This manager is created in QueueMgrWindow constructor, as a lots of > > > other classes, as ActionThread, which can be created only when BQM > > > window is displayed at the first time on screen... > > > > > > Gilles > > > > > >> Andi Clemens > > >> ----------------- > > >> www.digikam.org > > >> > > >> On Tuesday 30 November 2010 22:05:07 Gilles Caulier wrote: > > >>> Marcel, > > >>> > > >>> This method already exist : > > >>> > > >>> class QueueMgrWindow : public KXmlGuiWindow > > >>> { > > >>> > > >>> Q_OBJECT > > >>> > > >>> public: > > >>> ~QueueMgrWindow(); > > >>> > > >>> static QueueMgrWindow* queueManagerWindow(); > > >>> static bool queueManagerWindowCreated(); > > >>> > > >>> ... > > >>> > > >>> So it can be used in ContextMenuHelper... > > >>> > > >>> Gilles > > >>> > > >>> 2010/11/28 Marcel Wiesweg <[hidden email]>: > > >>> >> Digikam::QueueMgrWindow::QueueMgrWindow() at > > >>> >> queuemgrwindow.cpp:137 0x827d80a > > >>> >> Digikam::QueueMgrWindow::queueManagerWindow() at > > >>> >> queuemgrwindow.cpp:106 0x827d24b > > >>> >> Digikam::ContextMenuHelper::addQueueManagerMenu() at > > >>> >> contextmenuhelper.cpp:741 0x81b096a > > >>> >> Digikam::DigikamImageView::showContextMenuOnInfo() at > > >>> >> digikamimageview.cpp:222 0x81d3a92 > > >>> >> > > >>> >> We call this instruction chain whenever the context menu is > > >>> >> openend. But why? Wouldn't it be enough to just generate the > > >>> >> QueueMgrWindow without all this stuff? Especially when no images > > >>> >> have been added to the BQM? > > >>> > > > >>> > If the QueueManagerWindow is supposed to be a singleton, like the > > >>> > ImageWindow, there should be an additional method which returns the > > >>> > singleton pointer (or a bool) but does not create it. With > > >>> > K_GLOBAL_STATIC, there is a method exists() on the creator > > >>> > _______________________________________________ > > >>> > Digikam-devel mailing list > > >>> > [hidden email] > > >>> > https://mail.kde.org/mailman/listinfo/digikam-devel > > >>> > > >>> _______________________________________________ > > >>> Digikam-devel mailing list > > >>> [hidden email] > > >>> https://mail.kde.org/mailman/listinfo/digikam-devel > > >> > > >> _______________________________________________ > > >> Digikam-devel mailing list > > >> [hidden email] > > >> https://mail.kde.org/mailman/listinfo/digikam-devel > > > > _______________________________________________ > > Digikam-devel mailing list > > [hidden email] > > https://mail.kde.org/mailman/listinfo/digikam-devel > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |