#15038 closed defect (fixed)

The wxGTK clipboard multiply-connects

Reported by: dghart Owned by: vadz
Priority: normal Milestone: 2.9.5
Component: wxGTK Version: stable-latest
Keywords: Clipboard Cc:
Blocked By: Blocking:
Patch: yes

Description

(Skip this paragraph unless you want the background) CodeLite is a multi-tab IDE, each tab containing a wxStyledTextCtrl. For a year or more I'd noticed that, once I'd been using an instance for a week or two, actions like changing tabs got slower and slower until the instance became unusable. The wasn't easy to debug (Step 0: Run the app for 2 weeks...). Recently a new CodeLite plugin improved the situation: it slows things in an hour or so, and I've been able to track it down to the wxGTK clipboard.

Apply stctest.diff and run the stc sample. Ideally load a long file e.g. src/richtext/richtextbuffer.cpp. Calling the 'About' dialog will select all the text 200 times. Look at the wxLogDebug output (and listen to your cpu fan) and you'll see things progressively slow. Keep calling the dialog; it slows even more.

On interrupting, the backtrace (see bt.txt) was always in src/common/strconv.cpp:wxMBConvStrictUTF8::FromWChar, but this and the calling functions seemed innocent. I finally realised that it wasn't slow; it's just being called increasingly often. Uncomment the wxLog::AddTraceMask line (304) in the stc sample to demonstrate this.

The problem is that each time wxClipboard::AddData in src/gtk/clipbrd.cpp is called, it does g_signal_connect (m_clipboardWidget, "selection_get",....); I have little gtk knowledge and there's probably a better solution, but clipbrd.diff uses a static bool to restrict this to once. This makes the stc sample behaves normally, and there are no obvious regressions or relevant test failures.

Attachments (3)

bt.diff download (1.1 KB) - added by dghart 22 months ago.
clipbrd.diff download (692 bytes) - added by dghart 22 months ago.
stctest.diff download (943 bytes) - added by dghart 22 months ago.

Download all attachments as: .zip

Change History (5)

Changed 22 months ago by dghart

Changed 22 months ago by dghart

Changed 22 months ago by dghart

comment:1 in reply to: ↑ description Changed 22 months ago by vadz

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

Replying to dghart:

Apply stctest.diff and run the stc sample. Ideally load a long file e.g. src/richtext/richtextbuffer.cpp. Calling the 'About' dialog will select all the text 200 times. Look at the wxLogDebug output (and listen to your cpu fan)

Hey, this means that we can't change this behaviour.

The problem is that each time wxClipboard::AddData in src/gtk/clipbrd.cpp is called, it does g_signal_connect (m_clipboardWidget, "selection_get",....); I have little gtk knowledge and there's probably a better solution, but clipbrd.diff uses a static bool to restrict this to once. This makes the stc sample behaves normally, and there are no obvious regressions or relevant test failures.

I think we could just connect to this signal once in wxClipboard constructor without any bad effects but as I'm not totally sure about this, I'll use a variant of your patch instead.

Thanks for debugging this!

comment:2 Changed 21 months ago by VZ

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

(In [73518]) Don't connect to the same signal multiple times in wxGTK wxClipboard.

We called g_signal_connect("selection_get") in wxClipboard code each time its
AddData() method was called. This resulted in progressive but noticeable
slowdown as the handler was called more and more times.

Only connect to the handler once now.

Closes #15038.

Note: See TracTickets for help on using tickets.