I've tried to disable all plugins and use a fresh configuration file but nothing changed.... including CC, of course.
does anyone have any clues as to what the issue might be?- Try to turn of CC
I tried --safe-mode (which should disable CC and spell checker) .. still the same effect ..does anyone have any clues as to what the issue might be?- Try to turn of CC
-> if that help, try to only turn off real-time parsing of CC
- Try to turn off the SpellChecker plugin
- Try if other scintilla based editor like SciTE does slow-down, too
-> if so, its a window manager issue
I tried --safe-mode (which should disable CC and spell checker) .. still the same effect ..does anyone have any clues as to what the issue might be?- Try to turn of CC
-> if that help, try to only turn off real-time parsing of CC
- Try to turn off the SpellChecker plugin
- Try if other scintilla based editor like SciTE does slow-down, too
-> if so, its a window manager issue
scite scrolls just fine .. as i mentioned scite scrolls about 10x more per full-wheel-scroll than does c::b
What about wxWidgets samples (http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/samples/stc/) (if I understand correctly, wxScintilla has been integrated into wxWidget as wxStyledTextCtrl) ?
This is an old, old issue that hasn't been resolved. I spent a bunch of time trying to figure this out but I wasn't able to isolate the cause to a single factor. I can't remember if anyone tried running a minimal wxScintilla sample to see if the same performance issue shows up there. That may be worth exploring.
// Prevent having an event queue with wheel events that cannot be processed
// reasonably fast (see ticket #9057) by ignoring all of them that happen
// during the time interval corresponding to the time it took us to handle
// the last one.
If I remember correctly there are two different issues:
- the scrolling is slow, even if the scrollbar is dragged
- the scrolling in priciple is fast enough, but the amount of lines scrolled per mousewheel-delta is very low
// Prevent having an event queue with wheel events that cannot be processedThis sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded .. scite scrolls the same file at nearly 10x the lines per wheel..
// reasonably fast (see ticket #9057) by ignoring all of them that happen
// during the time interval corresponding to the time it took us to handle
// the last one.
The second issue is a wxWidgets restriction, because the mousewheel-event always returns three as linesperaction.This sounds like the only viable option .. I have a wedding coming up and am short on free time .. I'll look into it when I get a chance but I have no clue on when that will be .. If someone else can get to it before me, then by all means ..... :)
We could work around that by introducing a (configurable) factor that is multiplied with the default number of linesperaction, in the call to DoMousewheel in wxScintilla::OnMouseWheel.
It was neither a C::B bug nor a C::B patch.Quote from: wxScintilla::OnMouseWheel// Prevent having an event queue with wheel events that cannot be processedThis sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded .. scite scrolls the same file at nearly 10x the lines per wheel..
// reasonably fast (see ticket #9057) by ignoring all of them that happen
// during the time interval corresponding to the time it took us to handle
// the last one.
The second issue is a wxWidgets restriction, because the mousewheel-event always returns three as linesperaction.This sounds like the only viable option .. I have a wedding coming up and am short on free time .. I'll look into it when I get a chance but I have no clue on when that will be .. If someone else can get to it before me, then by all means ..... :)
We could work around that by introducing a (configurable) factor that is multiplied with the default number of linesperaction, in the call to DoMousewheel in wxScintilla::OnMouseWheel.
I don't have a slowdown here, so it might be related to the graphics driver.If I remember correctly there are two different issues:
- the scrolling is slow, even if the scrollbar is dragged
- the scrolling in priciple is fast enough, but the amount of lines scrolled per mousewheel-delta is very low
The first issue is the higher priority for me. On low end hardware, scrolling performance sucks (It's still noticeable, but good enough for me on my desktop). Others might feel more strongly about the mousewheel-delta.
I don't have a slowdown here, so it might be related to the graphics driver.I'm on Mint 12 - Lisa (oneiric) .. Using i7 intel video .. I installed scite from the repo (Version: 2.25-1) .. The scrolling is very fast (around 200-250 lines per full wheel) where c::b only does around 20
Did you test it with pure scite, so no wxwidgets-stuff is between scintilla and the system ?
This sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded ..I'd say the fact that C::B scrolls slowly is a single symptom of a more general problem, that is the overall slowdown of the whole IDE when dealing with text rendering. I don't code on linux no more these days, but from what I recall, selecting and even typing text could become laggy (I wrote it in my first post in this topic, by the way, and also here (http://forums.codeblocks.org/index.php/topic,9266.0.html)).
If I remember correctly there are two different issues:
- the scrolling is slow, even if the scrollbar is dragged
- the scrolling in priciple is fast enough, but the amount of lines scrolled per mousewheel-delta is very low
The first issue is the higher priority for me. On low end hardware, scrolling performance sucks (It's still noticeable, but good enough for me on my desktop). Others might feel more strongly about the mousewheel-delta.
I don't have a slowdown here, so it might be related to the graphics driver.
void Editor::OnScintillaUpdateUI(wxScintillaEvent &e)
{
...
//update line number
wxString message;
message << wxT("Ln ")
<< curLine+1
<< wxT(", Col ")
<< GetColumn(pos)
<< wxT(", Pos ")
<< pos;
// Always update the status bar with event, calling it directly causes performance degredation
DoSetStatusMessage(message, 1);
...
}
void Editor::DoSetStatusMessage(const wxString &msg, int col)
{
// fire custom event
wxCommandEvent e(wxEVT_UPDATE_STATUS_BAR);
e.SetEventObject(this);
e.SetString(msg);
e.SetInt(col);
wxTheApp->GetTopWindow()->GetEventHandler()->AddPendingEvent(e);
}
// Line number margin
#ifdef __WXMSW__
int pixelWidth = 4 + 5*TextWidth(wxSCI_STYLE_LINENUMBER, wxT("9"));
#else
int pixelWidth = 4 + 5*8;
#endif
// Show number margin according to settings.
SetMarginWidth(NUMBER_MARGIN_ID, options->GetDisplayLineNumbers() ? pixelWidth : 0);#if defined(__WXMAC__)
// turning off these two greatly improves performance
// on Mac
SetTwoPhaseDraw(false);
SetBufferedDraw(false);
#elif defined(__WXGTK__)
SetTwoPhaseDraw(true);
SetBufferedDraw(false);
#else // MSW
SetTwoPhaseDraw(true);
SetBufferedDraw(true);
#endif
dmoore: Have you tried to use a profiler? oprofile for example?
moi@home:~$ callgrind_control
No active callgrind runs detected.
dmoore: Is this perf: https://perf.wiki.kernel.org/index.php/Main_Page ?
I guess the biggest difference between C::B and the STC sample is the sheer size of C::B. Would it make sense that a single STC event will propagate through many more handlers in C::B than in a stripped down sample?Did you try:
Quote from: wxScintilla::OnMouseWheel// Prevent having an event queue with wheel events that cannot be processedThis sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded .. scite scrolls the same file at nearly 10x the lines per wheel..
// reasonably fast (see ticket #9057) by ignoring all of them that happen
// during the time interval corresponding to the time it took us to handle
// the last one.
Quote from: wxScintilla::OnMouseWheel// Prevent having an event queue with wheel events that cannot be processedThis sounds like the culprit .. So it must be overhead from c::b that causes the events to hang and be discarded .. scite scrolls the same file at nearly 10x the lines per wheel..
// reasonably fast (see ticket #9057) by ignoring all of them that happen
// during the time interval corresponding to the time it took us to handle
// the last one.
Given it looks like it is going to be hard to improve overall performance, why don't we come up with a better patch for this one.
What are the steps to reproduce the slow scrolling?
On my machine gentoo 64bit+core2quad+nvidia binary scrolling is responsive and non-laggy.
If we do so, we should post it in wxWidgets mailing list also, because it's a wxWidgets patch and not a C::B patch.
And it only affects the scrolling with the mouse-wheel and not the scrolling at all.
By the way making the amount of lines per wheel-click configurable is a good thing in my opinion.I think the problem with the scrolling is that there is no acceleration, not that the scrolling is slow.
Shall I prepare a patch for it ?
Shall I prepare a patch for it ?Feel free to do. I have some changes related to wxScintilla pending, but I can handle...
By the way making the amount of lines per wheel-click configurable is a good thing in my opinion.I think the problem with the scrolling is that there is no acceleration, not that the scrolling is slow.
Shall I prepare a patch for it ?
At least firefox seems to have some acceleration in it, but I may be wrong as my mouse doesn't have a lock which limits the rotations (the mechanism making the mouse click when scrolling).
Could you please test the attached patch to Editor.cxx.
It should optimize scrolling of just a few lines, but at least on gtk (when calling ScintillaWX::ScrollText() ) it seems to slow down scrolling a lot.
void Editor::ScrollText(int /* linesToMove */) {
//Platform::DebugPrintf("Editor::ScrollText %d\n", linesToMove);
Redraw();
}
void ScintillaWX::ScrollText(int linesToMove) {
int dy = vs.lineHeight * (linesToMove);
sci->ScrollWindow(0, dy);
sci->Update();
}
Index: src/sdk/wxscintilla/src/ScintillaWX.cpp
===================================================================
--- src/sdk/wxscintilla/src/ScintillaWX.cpp (revision 8138)
+++ src/sdk/wxscintilla/src/ScintillaWX.cpp (working copy)
@@ -417,7 +417,7 @@
void ScintillaWX::ScrollText(int linesToMove) {
int dy = vs.lineHeight * (linesToMove);
sci->ScrollWindow(0, dy);
- sci->Update();
+// sci->Update(); //causes slow-down on GTK+ systems (Linux)
}
void ScintillaWX::SetVerticalScrollPos() {
Could you please test the attached patch to Editor.cxx.Ah - my favourite again: "Error: Chunk info expected.". :( Nevermind - these few lines I can do by hand... :P
Could you please test the attached patch to Editor.cxx.Ah - my favourite again: "Error: Chunk info expected.". :( Nevermind - these few lines I can do by hand... :P
I will test it with tortoise later the day.Could you please test the attached patch to Editor.cxx.Ah - my favourite again: "Error: Chunk info expected.". :( Nevermind - these few lines I can do by hand... :P
So this is odd:I thought about doing this way, but I decided to patch scintilla's sources (again), because the (admittedly small) overhead for is not needed at all.Codevoid Editor::ScrollText(int /* linesToMove */) {
//Platform::DebugPrintf("Editor::ScrollText %d\n", linesToMove);
Redraw();
}
So if they hadn't done thisCodevoid ScintillaWX::ScrollText(int linesToMove) {
int dy = vs.lineHeight * (linesToMove);
sci->ScrollWindow(0, dy);
sci->Update();
}
(Editor is a base class of SctinillaWX)
Then there would be no lag.
We can probably also drop the crap related to ticket #9057. (Although it doesn't seem to do any harm either)
BTW, comparing scite with C::B without the sci->update call:
* by default, scite scrolls 4 lines per wheel motion vs 3 lines in C:::B.
* a full mousewheel motion (moving as much as possible in one motion) in scite scrolls about 70 lines vs 35 lines in C::B.
I personally prefer C::B's current behavior, but it would be good to add the customization to the lines per motion. But perhaps scite also allows for some acceleration of the step size upon repeated moves? That might be nice to have.
I thought about doing this way, but I decided to patch scintilla's sources (again), because the (admittedly small) overhead for is not needed at all.
I did not do any exact measuring which of the two ways is shorter.
But the original ScrollTo took about 35 ~ 50 ms per line and the "new" one takes 0 ~ 1 ms, so it does not really matter if it is takes another 0.5 ms or not I think.
so it is probably better to change ScintillWX instead of scintilla's sources (again)....meaning your patch is obsolete and superseeded by the ones of dmoore? I wonder if it has side-effects on Windows...
It's basically the same, it avoids the call of wxWindows::Update() on every scrol, which immediately updates the whole invalidated area.so it is probably better to change ScintillWX instead of scintilla's sources (again)....meaning your patch is obsolete and superseeded by the ones of dmoore? I wonder if it has side-effects on Windows...
As far as I see, it works fine on windows 7 with wx2.8 and actual trunk.
I will open a ticket there or probably reopen #9057 this evening.As far as I see, it works fine on windows 7 with wx2.8 and actual trunk.
Any thoughts on removing the ticket #9057 junk?
Also, the advantage of patching wx instead of scintilla is at least the wx guys are likely to accept the patch in the next 5 years. :)
That is good news! Does that mean we'll see these patches applied in the next nightly?We do not use wxSTC, but a more or less patrched version based on it.
It's basically the same, it avoids the call of wxWindows::Update() on every scrol, which immediately updates the whole invalidated area.It seems that matching brace highlights, which should be invalidated (and redrawn) no longer are consistently.
But the original scintilla Redraw() invalidates the whole client area and the other one (most likely) only the scrolled part.
int main()
{
return 0;
}|
I can not reproduce it here.It's basically the same, it avoids the call of wxWindows::Update() on every scrol, which immediately updates the whole invalidated area.It seems that matching brace highlights, which should be invalidated (and redrawn) no longer are consistently.
But the original scintilla Redraw() invalidates the whole client area and the other one (most likely) only the scrolled part.CodePlace the cursor where the pipe symbol is, then press the up arrow key once. The first curly brace remains highlighted.int main()
{
return 0;
}|
Could this be related to the changes discussed in this thread?
(Ubuntu LTS 32bit; svn 8328)
I can not reproduce it here.
word word word word word word word word
word word word word word
word word word word word word word word
word word
word word word
I confirm (ubuntu 12.04, latest trunk). Why do these features rely on the update call and other feature not?I can not reproduce it here.CodeSelect the last "word" - all of the words should be highlighted (this is normal). Press the up arrow key once. On Windows Vista; svn 8330, all the words except the last three remain highlighted.... word ...
If no one can duplicate it, maybe something is wrong with my computer. (However, I do not believe this is the case. These problems are not present in my tests of svn 8133.)
If I move the caret away from the selected word, the word gets unselected and all the other highlighted words are shown normal.
Index: src/sdk/cbeditor.cpp
===================================================================
--- src/sdk/cbeditor.cpp (revision 8351)
+++ src/sdk/cbeditor.cpp (working copy)
@@ -502,6 +504,8 @@
// Set Styling:
// clear all style indications set in a previous run (is also done once after text gets unselected)
m_pOwner->GetControl()->IndicatorClearRange(0, eof);
+ m_pOwner->GetControl()->Refresh();
// check that feature is enabled,
// selected text has a minimal length of 3 and contains no spaces
if (mh.modificationType & (SC_MOD_CHANGESTYLE | SC_MOD_CHANGEINDICATOR)) {
if (mh.modificationType & SC_MOD_CHANGESTYLE) {
pdoc->IncrementStyleClock();
}
if (paintState == notPainting) { // ***********************
if (mh.position < pdoc->LineStart(topLine)) {
// Styling performed before this view
Redraw();
} else {
InvalidateRange(mh.position, mh.position + mh.length);
}
}
if (mh.modificationType & SC_MOD_CHANGESTYLE) {
llc.Invalidate(LineLayout::llCheckTextAndStyle);
}
btw, either approach seems to work fine on my netbook (doesn't slow things down too much). I would still advocate reducing the number of ClearRange calls, because that could be expensive on a really big file.
I don't understand why this wouldn't also affect the wx demo.
ClearRange is only called once for every selection change, so it does not happen too often.
What makes me wonder, is that IncrementalSearch still works, but HighlightOccurrences does not.
And the ClearRange code is the same in both cases.
Why does it work in wxSTC then ?What makes me wonder, is that IncrementalSearch still works, but HighlightOccurrences does not.
And the ClearRange code is the same in both cases.
because (painstate==notpainting) == true for incremental search. IMHO it's a scintilla bug.
Why does it work in wxSTC then ?
It also uses scintilla internally and the chnage that discovered the issue is in ScintillaWx.cpp:DoPaint() .
Before the change Refresh was called from there (or more exactly from FullPaint()) .
Another strange thing:
if I do the exact same call to ClearRange from inside IncSearch (for the Indicator used in HighlightOccurences), it clears the indicators.
No, it's from inide a key-event handler.Another strange thing:
if I do the exact same call to ClearRange from inside IncSearch (for the Indicator used in HighlightOccurences), it clears the indicators.
Is that call from inside a handler to wxEVT_SCI_UPDATEUI ? I think that is why paintState != notPainting in the cbEditor code.
int func()
{
return 0;
}
word word word word word word word word /*line b*/
call(arg0,
arg1, arg2
)
word word word word word word word word /*line a*/
word word word word wordBisected: revision 8278 introduces the problem. Something must have gone wrong with the Scintilla update.I forgot to mention, that was on Windows.
Now I see it here also (I tested it with 8248).... which means that either I incorrectly bisected (which is a possibility), or there are multiple (platform specific?) items that are contributing to the problem. Although, it sounds as though the source may already have been found.
And what's more:
after using the wxScintilla UI-Event in the stc-sample to call HighlightOccurrences instead the wxUpdatUI event, the issue is there also.
That means you are right and it is most likely a scintilla and not a wxScintilla issue (bug?).
That was not clear, sorry.Now I see it here also (I tested it with 8248).... which means that either I incorrectly bisected (which is a possibility), or there are multiple (platform specific?) items that are contributing to the problem.
The no longer existing refresh might also be the cause for the not correctly working HighlightBraces, because the appropriate function is called from the UpdateUI function also.
Maybe we need something similar here (setting a flag that an UpdateUI-event occured and do the real work from inside an OnIdle call).
We would need just one flag for all painting related stuff inside the UpdateUI-function, even if we would have more things later.
The no longer existing refresh might also be the cause for the not correctly working HighlightBraces, because the appropriate function is called from the UpdateUI function also.
Makes sense. Doesn't that feature also rely on indicators?
QuoteMaybe we need something similar here (setting a flag that an UpdateUI-event occured and do the real work from inside an OnIdle call).
We would need just one flag for all painting related stuff inside the UpdateUI-function, even if we would have more things later.
I guess that would work, but doesn't it force an extra paint each keypress? (Probably doesn't make a difference to performance)
Until then every DoPaint-call which ended with paintState abandone did a Refresh() of the control.Wait a sec... you should also have a look at the scintilla repo. From what I see there is a bugfix recently which may cover this, too (I am unable to present a link to a diff though). Or is this really a wxScintilla issue?
It might be a scintilla issue, but it's discovered by a change in wxScintilla.Until then every DoPaint-call which ended with paintState abandone did a Refresh() of the control.Wait a sec... you should also have a look at the scintilla repo. From what I see there is a bugfix recently which may cover this, too (I am unable to present a link to a diff though). Or is this really a wxScintilla issue?
http://scintilla.hg.sourceforge.net/hgweb/scintilla/scintilla/rev/c39df2a9f97aYes, that's what I meant. I did only recall the part with "paintAbandoned". So its not related... that's fine.
But it is gtk3 and toolbar related and does not change anything.
Some platforms behave differently when redraw calls are made inside paints so may need to schedule a paint on idle. They also differ in the information they provide about the paint region so may require overriding PaintContains.It might be needed to paint in OnIdle-function as my patch doese.
I don't know which solution is the better one.
Index: src/sdk/wxscintilla/src/ScintillaWX.cpp
===================================================================
--- src/sdk/wxscintilla/src/ScintillaWX.cpp (revision 8358)
+++ src/sdk/wxscintilla/src/ScintillaWX.cpp (working copy)
@@ -911,7 +911,8 @@
if (paintState == paintAbandoned) {
// Painting area was insufficient to cover new styling or brace
// highlight positions
- FullPaintDC(dc);
+ FullPaint();
}
paintState = notPainting;
}
@@ -919,8 +920,12 @@
// Force the whole window to be repainted
void ScintillaWX::FullPaint() {
- wxClientDC dc(sci);
- FullPaintDC(&dc);
+#ifndef __WXMAC__
+ sci->Refresh(false);
+#endif
+ sci->Update();
}
Reverting part of the 3.2.2 patch as follows would fix the problem:If it works, feel free to commit, but please encapsulate it into /* C::B begin */, /* C::B end */ comments. In fact, I was indeed a bit curious about that change, because I also saw that in SciTE and ScintillaQT this is handled differently. Hence I thought "the wx guys should know" but it seems I was wrong. I didn't realise this bug until posted here... sorry.