User forums > Using Code::Blocks
Slow scrolling? [Ubuntu]
p2rkw:
I found another strange issue, sometimes curly braces aren't correctly highlighted.
Here's my test case:
--- 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 word
--- End code ---
Select "word" in line 'a', and move cursor up to func(). Notice that highlight gone when cursor meet ')' (whole screen redraw?), curly braces should by highlighted correctly. After that move cursor down to '}' - matching curly bracket isn't highlighted, but if you for instance add breakpoint or toggle bookmark, brace will be highlighted.
Alpha:
--- Quote from: Alpha on September 05, 2012, 02:28:09 am ---Bisected: revision 8278 introduces the problem. Something must have gone wrong with the Scintilla update.
--- End quote ---
I forgot to mention, that was on Windows.
--- Quote from: jens on September 05, 2012, 06:34:53 am ---Now I see it here also (I tested it with 8248).
--- End quote ---
... 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.
--- Quote from: jens on September 05, 2012, 10:07:05 pm ---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?).
--- End quote ---
Jenna:
--- Quote from: Alpha on September 06, 2012, 05:27:10 am ---
--- Quote from: jens on September 05, 2012, 06:34:53 am ---Now I see it here also (I tested it with 8248).
--- End quote ---
... which means that either I incorrectly bisected (which is a possibility), or there are multiple (platform specific?) items that are contributing to the problem.
--- End quote ---
That was not clear, sorry.
I meant I tested with 8248 before (when I had no issue).
It's definiotely 8278.
Until then every DoPaint-call which ended with paintState abandone did a Refresh() of the control.
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.
In cbAuiNotebook I stumbled over similar issues when doing the MinimizeFreeSpace-calls (to move the tabs as far to the right as possible, if there is free space).
It did not work from inside the OnResize event, so I just set a flag in the OnResize event-chain and do the real work in an OnIdle call.
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.
I will not be at home today, so I can not follow the discussion until this evening.
dmoore:
--- Quote from: jens on September 06, 2012, 05:42:49 am ---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.
--- End quote ---
Makes sense. Doesn't that feature also rely on indicators?
--- Quote ---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.
--- End quote ---
I guess that would work, but doesn't it force an extra paint each keypress? (Probably doesn't make a difference to performance)
Jenna:
--- Quote from: dmoore on September 06, 2012, 05:55:10 am ---
--- Quote from: jens on September 06, 2012, 05:42:49 am ---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.
--- End quote ---
Makes sense. Doesn't that feature also rely on indicators?
--- End quote ---
Yes !
--- Quote from: dmoore on September 06, 2012, 05:55:10 am ---
--- Quote ---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.
--- End quote ---
I guess that would work, but doesn't it force an extra paint each keypress? (Probably doesn't make a difference to performance)
--- End quote ---
Why should there be an extra paint ?
You can try the attached patch.
I also moved the NotifyPlugins call into the OnIdle-function, to ensure plugins that want to paint if the UI is updated do not run into the same trouble.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version