CPU 100% when moving mouse in CB (toolbar/editor/manager/etc)

[bughunter2]

As the topic title says, when moving the mouse, the CPU usage reaches 100%.

I've searched for topics like these, and have read in some topic that thomas recommended to remove the lines with "EVT_UPDATE_UI" to test if the CPU usage is still that high. I've updated to the last SVN, removed these lines and rebuilt CB.

The CPU usage is now about 44% max if I move the mouse inside CB.

FYI: I have a 2000dpi mouse, 2GB of RAM and an AMD64 2.2GHz
(edit: however in CB I set the mouse's dpi to 800, there are buttons on the mouse to change the dpi)

[thomas]

Hmm not sure if that's good or bad  :?

Good insofar as if it really reduces the load by one half for you, then we have a hint that my theory may at least partially be right (though other people have reported no visible difference).

Bad insofar as those messages are needed to keep the menu states in sync, and it'll be a horror to remove them...

[Pecan]

Hmm not sure if that's good or bad  :?

Good insofar as if it really reduces the load by one half for you, then we have a hint that my theory may at least partially be right (though other people have reported no visible difference).

Bad insofar as those messages are needed to keep the menu states in sync, and it'll be a horror to remove them...

ummmmm. Maybe not. Notice that in main.cpp the same code is being  executed over and over again for a single UI cycle. For example:

Code

    EVT_UPDATE_UI(idEditUndo, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditRedo, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditCopy, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditCut, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditPaste, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditSwapHeaderSource, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditGotoMatchingBrace, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditFoldAll, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditUnfoldAll, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditToggleAllFolds, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditFoldBlock, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditUnfoldBlock, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditToggleFoldBlock, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditEOLCRLF, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditEOLCR, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditEOLLF, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditEncoding, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditSelectAll, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditBookmarksToggle, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditBookmarksNext, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditBookmarksPrevious, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditCommentSelected, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditAutoComplete, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditUncommentSelected, MainFrame::OnEditMenuUpdateUI)
    EVT_UPDATE_UI(idEditToggleCommentSelected, MainFrame::OnEditMenuUpdateUI)

This is just one example of many.

Is there anyway on secondary calls to set a flag that says, "Hey, I've already done this for now"; then on the last call clear the flag?

Is there any correlation between OnIdle and UI updates? If so, a flag might be set there?

Can a timer be set to only honor UI calls every xxx mils?

[bughunter2]

Actually I just opening some files and closed them, tried some menu's. Nothing weird happened on the rebuilt CB (without the update UI events)

Seems it's not that much of a horror? Maybe it's because the UI is indeed already updated as Pecan said.

[bughunter2]

Any new info on this?

[thomas]

The main problem lies in two things. First, during the UpdateUI handler, menu items and other controls are enabled/disabled and this fires off new UpdateUI messages. Second, wxWidgets sends messages to many objects that aren't updated at all, but just happen to be a child of the same window... for example the editor is notified if you move the mouse over the menu bar or over the project manager.

I'm not sure whether it would work to only listen to the events using one single handler. In any case that would mean to rely on a misfeature (which may be implemented differently on another platform or in another version).

Setting a flag to not process the events won't do much. Our message processing is not what eats up the CPU time, it is pushing a several thousand events through the message queue. wxWidgets will still send them, even if we ignore them.
Using a timer and poll events every 100 ms or so would be great, but unluckily I don't see a way how you can do that with wxWidgets. For all I know there are no functions to actually manipulate the event queue in such a way as we would need (peek at and pop off one message, then remove all duplicates).

A solution that would work would be to move the control updating code to a manager that keeps track of and handles the states of all controls, but that would require an awful lot of work in the present design. Knowing that this design will be replaced one not-so-far day in the future, I'm reluctant to do that work, too.

[Biplab]

Using a timer and poll events every 100 ms or so would be great, but unluckily I don't see a way how you can do that with wxWidgets. For all I know there are no functions to actually manipulate the event queue in such a way as we would need (peek at and pop off one message, then remove all duplicates).

AFAIK, No timer is necessary. You need to set UpdateInterval during app initialization. The following code should do the job.

Code

wxUpdateUIEvent::SetUpdateInterval(100);

It will set the value of updating ui to 100 milliseconds.

I tested it sometimes back for one of my app.

Regards,

Biplab

[thomas]

I don't see why this should reduce the CPU load, as it does not reduce the actual number of events being sent, but... I tried it, and it really works

On my machine, this one line of code reduces the load from 26-29% to 3-4%.

Good catch, Biplab 

[Biplab]

Thanks a lot for testing it.

On my machine, this one line of code reduces the load from 26-29% to 3-4%.

So are we going to put this to main repo?

Regards,

Biplab

[thomas]

Did that before posting already.

[Biplab]

Thanks for the update.

There are couple of interesting functions in wxUpdateUIEvent class. Function CanUpdate() can be helpful in reducing the load further. It checks whether to send Update event to a window or not.

I don't have in-depth knowledge of event system. But, IMHO, this can be helpful in some ways.

Regards,

Biplab

[bughunter2]

Hey guys, this worked for me, just about 2 - 3 % CPU usage now, astonishing!

However, I was thinking of something. Because the UI is updated once in 100ms, the CPU usage of course becomes less, because it's just busy for once in 100ms.

But won't the queue get full of update messages? I mean when the UpdateUI handler sends new UpdateUI messages because of updating, it would mean we can get some lag since the messages are only processed once in 100ms?

What I mean with the lag is, something of 100ms ago is actually processed about 100ms later, while it may not be necessary anymore at that time. However, as the message queue is designed as LILO (I may hope so), this won't be a problem.

[Biplab]

What I mean with the lag is, something of 100ms ago is actually processed about 100ms later, while it may not be necessary anymore at that time. However, as the message queue is designed as LILO (I may hope so), this won't be a problem.

AFAIK, the if you set update interval, UpdateUI event will be sent to the window only at those intervals. So in between these time window should remain idle. But I'm not sure how it has been implemented in wx.

[bughunter2]

Yes, but meanwhile the window is idle, aren't there messages queued for the next update?

EDIT: by reading the previous posts, I see the update thing is something in wx itself. Now I understand it'll update every 100ms but of course won't queue hundreds of update messages. Thanks Biplab