Im currently running a Linux From Scratch Based System I compiled and its running wx 2.6.3
and gcc 4.0.3
I was reading around about possible reasons for the image list stuff since I thought it erroring might of been the cause of the slow down.
In one of the post it said the UpdateUI needed cleaned up, so I commented out all the events in the src/src/main.cpp and slowly uncommented sections.
like I thought it only hit a massive slow down when the plugins events were added. so I figured it must be one of the plugins.
with all the events back on I went into the plugin manager and disabled a couple and when I got to the compiler which is right now 0.99
everything stopped lagging up. re-enabled all the other plugins and still no lag re-enabled compiler lag back dissabled lag gone..
from what I can tell is the compiler is the only one that adds its own tool bars and im guessing it has its own events that might lap over the main windows events or something like that.
and when one updates its self the other does and it keeps looping.
This is only a guess right now on the possible cause of the two reacting to each other. im going to dig deeper.
Edit: I found the source of the massive slow downs and cpu peeks.. not sure what to do with it right now though.
in file: src/plugins/compilergcc.cpp
the events that have to do with menu handling if any are added they add a little bit of slow down certain ones add more then others but if you have a good set of them on
you get the massive slow down.
Edit2:
EVT_UPDATE_UI(idMenuCompile, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCompileTarget, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCompileFromProjectManager, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuProjectCompilerOptions, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuTargetCompilerOptions, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuTargetCompilerOptionsSub, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCompileFile, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCompileFileFromProjectManager, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuRebuild, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuRebuildTarget, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuRebuildFromProjectManager, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCompileAll, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuRebuildAll, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuClean, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCleanAll, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCleanTarget, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCleanFromProjectManager, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuCompileAndRun, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuRun, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuKillProcess, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuSelectTarget, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuNextError, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuPreviousError, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuClearErrors, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuExportMakefile, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idMenuSettings, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idToolTarget, CompilerGCC::OnUpdateUI)
EVT_UPDATE_UI(idToolTargetLabel, CompilerGCC::OnUpdateUI)
as you will notice all of these point to CompilerGCC::OnUpdateUI
when i commented out all of this function except the skip event and turned back on all the events the system had no cpu spikes.. so this is most likely where
the trimming needs done.. or some function that is used inside of this is using to many cycles like the project code or something.. will dig deeper.
Edit3: I found the exact line causing the problem now.
line: 3114
in file: src/plugins/compilergcc.cpp
3113 // Project menu
3114 mbar->Enable(idMenuProjectCompilerOptions, !running && prj);
if you comment this out the program has no real cpu spikes. since im running dual core system it only spikes up to 60% but if i had a single core it would be 100%
since im new to this code im not exactly sure why this one line causes the problem but I know it does. I would love if someone could tell me.
but if they cant I will look into it more.
btw if i didnt mention it yet the svn is 3780
on a side not if you actually click build options, i waited about two minutes and the dialog finally poped up. the about another 30 seconds and the option screen was finally showing.
in the current state the option screen is useless since you are not ever really able to select any options. or anything.
for testing i tryed both with the code as i pointed out being the problem commented and un commented and same results..
build options is broken at least if i have a project or not. side not the project was a empty type not sure if this matters.
Hmm, I'm just curious what will be the result, could you try the following code ? :
if ( mbar->IsEnabled(idMenuProjectCompilerOptions) != ( !running && prj ) )
{
mbar->Enable(idMenuProjectCompilerOptions, !running && prj);
}
BYO
Here's the code I use to make patches.
SET PATH=C:\Program Files\Subversion\bin
svn.exe diff --extensions --unified --extensions --ignore-eol-style > filename-unix.patch
PAUSE
Here's the command I apply the patch with
unix2dos --newfile filename-unix.patch filename.patch
patch --backup-if-mismatch --unified --strip=0 --ignore-whitespace --forward --input=filename.patch
Note: I am using the "patch" command from UnxUtils from
http://sourceforge.net/projects/unxutils
Note: I am using the "unix2dos" command from MinGW
http://sourceforge.net/projects/mingw/
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721&release_id=158859
(mingw-utils-0.3)
Here's you patch formatted that way.
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 3790)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -521,6 +521,8 @@
if (!CheckProject())
return;
+ cbProject* prj = Manager::Get()->GetProjectManager()->GetActiveProject();
+ bool running = IsRunning();
if (!data || data->GetKind() == FileTreeData::ftdkUndefined)
{
// popup menu in empty space in ProjectManager
@@ -536,6 +538,10 @@
menu->Append(idMenuCleanFromProjectManager, _("Clean"));
menu->AppendSeparator();
menu->Append(idMenuProjectCompilerOptions, _("Build options"));
+ menu->Enable(idMenuCompileFromProjectManager, !running && prj);
+ menu->Enable(idMenuRebuildFromProjectManager, !running && prj);
+ menu->Enable(idMenuCleanFromProjectManager, !running && prj);
+ menu->Enable(idMenuProjectCompilerOptions, !running && prj);
}
else if (data && data->GetKind() == FileTreeData::ftdkFile)
{
@@ -545,6 +551,7 @@
// popup menu on a compilable file
menu->AppendSeparator();
menu->Append(idMenuCompileFileFromProjectManager, _("Build file"));
+ menu->Enable(idMenuCompileFileFromProjectManager, !running && prj);
}
}
}
@@ -3090,15 +3097,11 @@
{
mbar->Enable(idMenuCompile, !running && (prj || ed));
mbar->Enable(idMenuCompileAll, !running && prj);
-// mbar->Enable(idMenuCompileFromProjectManager, !running && prj);
mbar->Enable(idMenuCompileFile, !running && ed);
-// mbar->Enable(idMenuCompileFileFromProjectManager, !running && prj);
mbar->Enable(idMenuRebuild, !running && prj);
mbar->Enable(idMenuRebuildAll, !running && prj);
-// mbar->Enable(idMenuRebuildFromProjectManager, !running && prj);
mbar->Enable(idMenuClean, !running && prj);
mbar->Enable(idMenuCleanAll, !running && prj);
-// mbar->Enable(idMenuCleanFromProjectManager, !running && prj);
mbar->Enable(idMenuCompileAndRun, !running && (prj || ed));
mbar->Enable(idMenuRun, !running && (prj || ed));
mbar->Enable(idMenuKillProcess, running);
@@ -3109,9 +3112,6 @@
// mbar->Enable(idMenuClearErrors, cnt);
mbar->Enable(idMenuExportMakefile, false);// !running && prj);
-
- // Project menu
- mbar->Enable(idMenuProjectCompilerOptions, !running && prj);
}
// enable/disable compiler toolbar buttons
I'm afraid to say that the patch is not of much relevance.
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 3790)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -536,6 +538,10 @@
menu->Append(idMenuCleanFromProjectManager, _("Clean"));
menu->AppendSeparator();
menu->Append(idMenuProjectCompilerOptions, _("Build options"));
+ menu->Enable(idMenuCompileFromProjectManager, !running && prj);
+ menu->Enable(idMenuRebuildFromProjectManager, !running && prj);
+ menu->Enable(idMenuCleanFromProjectManager, !running && prj);
+ menu->Enable(idMenuProjectCompilerOptions, !running && prj);
}
else if (data && data->GetKind() == FileTreeData::ftdkFile)
{
If a project is running, then pop-up menus, mentioned in line 536,6 +538,10 are not created at all. So there is no point of disabling them. Look at the following code in plugins/compilergcc/compilergcc.cpp:519
if (type != mtProjectManager || !menu || IsRunning())
return;
So if a project is running, the menu at Project Manager is Not created.
idMenuProjectCompilerOptions denotes the menu id of Build options in Project menu and idMenuProjectCompilerOptionsFromProjectManager represents menu option in Project Manager. So if you apply the following patch, then basically you are disabling updating of Project menu when a project is being built. The same convention is followed for other menu items, too.
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 3790)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -3109,9 +3112,6 @@
// mbar->Enable(idMenuClearErrors, cnt);
mbar->Enable(idMenuExportMakefile, false);// !running && prj);
-
- // Project menu
- mbar->Enable(idMenuProjectCompilerOptions, !running && prj);
}
There were couple of typos in that file, which I've fixed in the latest revision. I'm not posting the patch which you can see at the following link.
http://svn.berlios.de/viewcvs/codeblocks?rev=3791&view=rev
Regards,
Biplab
sofar it has to do with a couple things in the compileroptionsdlg.cpp
first off it does not like this at all this is one of the items causing big problems
// remove "Compiler" buttons
wxWindow* win = XRCCTRL(*this, "btnAddCompiler", wxButton);
wxSizer* sizer2 = win->GetContainingSizer();
sizer2->Clear(true);
sizer2->RecalcSizes();
sizer2->Layout();
next one it really does not like either is
for some reason it likes DoFillOthers();
im still testing the code but i think all the other DoFills are causing the same kind of problem.
ok i found the exact line causing the problems
// project settings
nb->DeletePage(7); // remove "Other" page
nb->DeletePage(4); // remove "Programs" page
// remove "Compiler" buttons
wxWindow* win = XRCCTRL(*this, "btnAddCompiler", wxButton);
wxSizer* sizer2 = win->GetContainingSizer();
sizer2->Clear(true);
sizer2->RecalcSizes();
sizer2->Layout();
all of these are causing the problem if you comment them out and click on build options it loads instantly..
i think the deletes are the same problems as the bad events it passing bad ids and casing infinite loops since there not there.. as for the remove compiler button not sure why its causing problems yet.
EDIT: UPDATE
these are the real trouble makers..
nb->DeletePage(7); // remove "Other" page
EDIT: ok the above two are the only ones. finally narrowed it down.
for one you do a DoFillOther but i already found out that normally slows down loading the window not locking it up.. but the DoFillTree locks it up when the deleteoptions is un commented
EDIT: Figured out why the clear was causing problems the true passed to it was the problem
that got rid of that error all thats left if fixing the problem caused by the delete of other
ok i fixed the finall error
Was:
nb->DeletePage(7); // remove "Other" page
Now:
nb->RemovePage(7); // remove "Other" page
for some reason delete page causes a problem here to i decided to try out remove page and it removes it from the list and no lock ups.
i will work on getting a patch made.