Increased CPU utilization due to SC_WIN_IDLE messages

54 views
Skip to first unread message

ekopa...@gmail.com

unread,
Jan 25, 2025, 4:41:28 PMJan 25
to scintilla-interest
I use Scintilla within a Windows dialog.
If I now use multiple views within the dialog,
then there is increased CPU utilization due to SC_WIN_IDLE messages.

Here is an example setup for illustration
The DIAGNOSTICS dialog has the following methods, among others

```Rust
    ...
    pub fn create_doc(&self) -> isize {
        self.editor.call(SCI_CREATEDOCUMENT, 0, 0)
    }

    pub fn release_doc(&self, doc: isize) {
        self.editor.call(SCI_RELEASEDOCUMENT, 0, doc);
    }

    pub fn switch_doc(& mut self, new_doc: isize) {
        if new_doc != self.current_doc {
            let current_doc = self.editor.call(SCI_GETDOCPOINTER, 0, 0);
            self.editor.call(SCI_ADDREFDOCUMENT, 0, current_doc);
            self.editor.call(SCI_SETDOCPOINTER, 0, new_doc);
            self.editor.call(SCI_SETTABWIDTH, 2, 0);
            self.current_doc = new_doc;
        }
    }
    ...
```


other code calls it

```Rust
    if self.diagnostic_view == -1 {
        self.diagnostic_view = DIAGNOSTICS.create_doc();
    }
    DIAGNOSTICS.switch_doc(self.diagnostic_view);
```


If this Scintilla control now receives text,
it results in a large number of SC_WIN_IDLE (5001) messages being received,
which leads to increased CPU utilization.

procid  dialog       timestamp ms
[16816] diagnostics  1737838727402 HWND(0xd0866) 5001 WPARAM(2273467515) LPARAM(0)
[16816] diagnostics  1737838727409 HWND(0xd0866) 5001 WPARAM(2273467515) LPARAM(0)
[16816] diagnostics  1737838727417 HWND(0xd0866) 5001 WPARAM(2273467515) LPARAM(0)
[16816] diagnostics  1737838727420 HWND(0xd0866) 5001 WPARAM(2273467515) LPARAM(0)
[16816] diagnostics  1737838727422 HWND(0xd0866) 5001 WPARAM(2273467515) LPARAM(0)
...


which only subsides again when the document no longer contains any text.

My subclassing code

```Rust
extern "system" fn subclassed_scintilla_proc(hwnd: HWND, msg: u32, wparam: WPARAM, lparam: LPARAM, _uid_subclass: usize, _dw_ref_data: usize) -> LRESULT {
    use std::time::{SystemTime, UNIX_EPOCH};
    if let Ok(n) = SystemTime::now().duration_since(UNIX_EPOCH) {
        plugin_utils::helper::output_debug_string(&format!("diagnostics {:>14?} {hwnd:?} {msg} {wparam:?} {lparam:?} \n", n.as_millis()));
    }

    if msg == WM_GETDLGCODE {
        return LRESULT((DLGC_WANTARROWS | DLGC_WANTCHARS) as isize);
    }
    unsafe { DefSubclassProc(hwnd, msg, wparam, lparam) }
}
```


Btw. even if I do not subclass the Scintilla control, the CPU load is increased.
Am I missing something here?

Thx
Eren

Neil Hodgson

unread,
Jan 25, 2025, 6:22:14 PMJan 25
to Scintilla mailing list
ekopalypse:

> I use Scintilla within a Windows dialog.
> If I now use multiple views within the dialog,

Are there multiple views on a single document?

> then there is increased CPU utilization due to SC_WIN_IDLE messages.

There should only be a need for continued idle processing when word wrap or idle styling is enabled. If either of these is on, try with them turned off. Otherwise put a trace inside idle processing (Editor::Idle) to see what it thinks is being worked on. Doing work inside SCN_UPDATEUI can slow things down and modifying Scintilla there could cause more processing.

Outstanding idle messages should be capped at 1 but there could be some cases where more occur.

The trace shows subsequent SC_WIN_IDLEs (due to the same wParam start time) not originating SC_WIN_IDLEs from the timer firing which would have a 0 wParam.

Neil

ekopa...@gmail.com

unread,
Jan 26, 2025, 6:34:04 AMJan 26
to scintilla-interest
Hi Neil,
sorry for being misleading, no, there are multiple documents in a single window so I switch between them using SCI_SETDOCPOINTER.
When I run through the code in the debugger it looks slightly different

diagnostics  1737887838357 HWND(0x808b4) 5001 WPARAM(0) LPARAM(1)
diagnostics  1737887839368 HWND(0x808b4) 5001 WPARAM(2322579484) LPARAM(0)

and they are caused by needIdleStyling being true.

This seems to be due to the fact that Npp has now enabled IdleStyling for new scintilla controls.
After I disabled it again in my initialization routine, the high CPU load is gone.
But why is this happening at all? If I use it only with the one document, so the current document is always overwritten, the needIdleStyling does not generate this amount of messages, more precisely, IdleStyle is not called at all, because needIdleStyling is wrong.
And since Npp does not have this problem and uses multiple documents like in my dialog, this could indicate that CreateWindow and CreateDialog behave differently in this regard. Hmm, I will test if a standalone application behaves the same way with CreateWindow and CreateDialog.

Thx
Eren


Neil Hodgson

unread,
Jan 26, 2025, 5:25:42 PMJan 26
to scintilla...@googlegroups.com
ekopalypse:

> After I disabled it again in my initialization routine, the high CPU load is gone.
> But why is this happening at all? If I use it only with the one document, so the current document is always overwritten, the needIdleStyling does not generate this amount of messages, more precisely, IdleStyle is not called at all, because needIdleStyling is wrong.

More information should be gathered to diagnose this behaviour. Is the
style setting working correctly or does it have a bug? In a similar
issue, there was a problem with the search result lexer in Notepad++
that repeatedly re-lexed text because it didn't mark the text as
styled.

Neil
Reply all
Reply to author
Forward
0 new messages