Opened 19 months ago

Closed 8 weeks ago

#14938 closed defect (fixed)

wxStyledTextCtrl use cpu when idle unde cocoa

Reported by: bcteh Owned by: csomor
Priority: normal Milestone:
Component: wxOSX-Cocoa Version: 2.9.4
Keywords: wxStyledTextCtrl Cc:
Blocked By: Blocking:
Patch: yes

Description

For stc sample on OS X cocoa build,
When the sample program at background/idle,
it still using 0.6~0.7% of cpu.

Another example:
CodeLite,
Open 3 to 4 files, the cpu is use between 3.7% to 6%.

Attachments (2)

stctest.cpp download (30.7 KB) - added by bcteh 19 months ago.
This is a modified one of stc sample file, it contain wxTextCtrl and aui notebook
stc-timer.patch download (548 bytes) - added by plorkyeran 8 weeks ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 19 months ago by robind

There is a timer in STC that is used for various things, like blinking the caret, etc. That is probably the source of the activity you are seeing. You may want to try with a current trunk snapshot of the code, I think there has been some changes in wxOSX that will help reduce that, but I doubt that there will ever be a 0% reading when there is an STC in the application.

comment:2 Changed 19 months ago by bcteh

Thank for advice.
After commented the timer, the cpu reading is 0%.

The handling of idle event on stc is not working
and the timer should be turn off if stc control is not visible.

Get the source from https://github.com/wxWidgets/wxWidgets
is this the latest ? just test for stc sample, not much difference,
still show cpu 0.6~0.7%.

That is my workaround
1) add a procedure to turn on/off timer on stc
2) On Frame::Activated to turn on/off the timer

For stc control that is invisible, turn is off.

That i get reading 0% when the application is not activated.
Sure, this is not the correct way for solve this.

The source of stc already handling this but it didn't work on cocoa build.

comment:3 follow-up: Changed 19 months ago by bcteh

The issue is related to focus of stc.
When click on other control, the cursor still blinking on stc.
First i thought that is the behavior of osx text editor.
after compare to xcode, that is difference.

The timer will trigger the paint event on stc,
that cause use of a lot of cpu resources. I guess only :)

That is not 0.6~0.7% only. It depend of that setting of stc.
For my application and codelite, it used about 1.5~2.0 for each editor.
That can easily reach more than 8%.

comment:4 in reply to: ↑ 3 Changed 19 months ago by robind

Replying to bcteh:

The issue is related to focus of stc.
When click on other control, the cursor still blinking on stc.

The caret blinking when not active issue has been fixed in svn trunk for some time.

comment:5 Changed 19 months ago by bcteh

I apply the patch from here
http://trac.wxwidgets.org/ticket/14142 to 2.94
and
also download the latest sources ( Daily Snapshot)

It seem like didn't solve it completely.

The stc become better (0.2% cpu) and also lost focus.

But at my program i still can see two cursor blinking one in wxTextCtrl and
one in stc and also didn't lost focus when application not activated.

Will try to make a small sample to test again.

Changed 19 months ago by bcteh

This is a modified one of stc sample file, it contain wxTextCtrl and aui notebook

comment:6 Changed 19 months ago by bcteh

Attached stctest.cpp

Copy/Replace the stc sample file and remember link with aui lib.

Will show two cursor blink

comment:7 Changed 18 months ago by bcteh

  • Milestone set to 2.9.5

comment:8 Changed 15 months ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

the fix for #12267 , r65382 leads to a suppression of the focus kill for the stc

comment:9 Changed 15 months ago by SC

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [73967]) deactivating r65382 see #12267 (which does not seem to happen anymore even without this change), fixes #14938,

comment:10 Changed 8 weeks ago by plorkyeran

  • Patch set
  • Resolution fixed deleted
  • Status changed from closed to reopened

This is still sometimes a significant issue with latest trunk. While the actual work done in wxSTC's timer handler is utterly trivial, unconditionally running a 100ms timer means that a wxSTC instance existing anywhere in the application results in ten idle events being generated per second indefinitely.

The attached patch simply stops wxSTC's timer when it doesn't have focus, which drops my average wakeups per second (as reported by Xcode) when minimized from 10 to less than 1 and doesn't appear to impact anything that the timer is used for.

Changed 8 weeks ago by plorkyeran

comment:11 Changed 8 weeks ago by vadz

  • Milestone 2.9.5 deleted

Thanks! Should this be applied to 3.0 branch as well?

comment:12 Changed 8 weeks ago by VZ

  • Resolution set to fixed
  • Status changed from reopened to closed

In 76665:

Stop Scintilla timer when the control doesn't have focus.

This avoids excessive CPU load due to generating completely unnecessary timer
notifications for every wxSTC control in a program.

Closes #14938.

Note: See TracTickets for help on using tickets.