UpdateUI Events Not Exactly the problem

[devilsclaw]

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:

Code

     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

Code

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.

[byo]

Hmm, I'm just curious what will be the result, could you try the following code ? :

Code

if ( mbar->IsEnabled(idMenuProjectCompilerOptions) != ( !running && prj ) )
{
    mbar->Enable(idMenuProjectCompilerOptions, !running && prj);
}

BYO

[mandrav]

Please go on rambling, you will soon fix all remaining bugs :lol:
That's the reason I 'm not responding in this topic: you 're doing fine on your own .

Good job :mrgreen:

[stahta01]

Here's the code I use to make patches.

Code

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

Code

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.

Code

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

[Biplab]

I'm afraid to say that the patch is not of much relevance.

Code

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

Code

    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.

Code

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

[devilsclaw]

ok thanks.. and tested out seems to work fine..

hehe well at least i had fun while it lasted.

[Biplab]

ok thanks.. and tested out seems to work fine..

Does it solve the CPU spike problem which you were getting pointing to that line? IMO, it should get fixed.

[devilsclaw]

yes it did.. not sure why but it did.

only problem now is that the Build Options when you click it take up 100% of one of my cpu's the screen shows up a about 1 - 2 minutes after and after that
since the events are still wrapping like crazy i have to force kill the program.. i traced it into the compileroptionsdlg.cpp

also there is a configure that is used that takes a single argument but i cant find the code where its actually defined.. i can see one that takes two and one that takes none but not one.

and the ones that take none are in different parts of the project.

[Biplab]

yes it did.. not sure why but it did.

Thanks for the update.

IMO, it was due to the typo. Earlier C::B was trying to update menu id idMenuProjectCompilerOptions and it was pointing to a non-existent menu id (As it was not created during menu creation). Thus that line was virtually making wx to look for all possible menu ids pushing the CPU usage up. But I'm not very sure.

only problem now is that the Build Options when you click it take up 100% of one of my cpu's the screen shows up a about 1 - 2 minutes after and after that
since the events are still wrapping like crazy i have to force kill the program.. i traced it into the compileroptionsdlg.cpp

This problem needs further investigation.

also there is a configure that is used that takes a single argument but i cant find the code where its actually defined.. i can see one that takes two and one that takes none but not one.

and the ones that take none are in different parts of the project.

There are couple of configure()s. The configure() that exists in compilergcc can take one or two arguments.

Download the SDK manual if you want to know more on them.

http://prdownload.berlios.de/codeblocks/codeblocks_sdk_doc_r3605.chm

Regards,

Biplab

[devilsclaw]

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

Code

        // 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

Code

        DoFillTree();

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.

[devilsclaw]

ok i found the exact line causing the problems

Code

        // 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..

Code

nb->DeletePage(7); // remove "Other" page

Code

sizer2->Clear(true);

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

Code

sizer2->Clear();

that got rid of that error all thats left if fixing the problem caused by the delete of other

[devilsclaw]

even though the changing the clear fixed the one error, its best to leave it un commented because it causes dialog display problems. the rest is find.. the delete is still a problem.

i think its deleting something other then the other

[devilsclaw]

ok i fixed the finall error

Was:

Code

nb->DeletePage(7); // remove "Other" page

Now:

Code

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.

[byo]

Sending patch is nothing bad, but maybe some bug report would be better thing if you're not sure about the patch. Anyway, either patch or bug report would be nice

BYO