Mysterious phenomena: style index can slow down scrolling a lot

[Hibou57]

I came to this strange case in this message of another discussion: #734 (comment)

The test case is this one, to put in your init.lua. You will have to remove it later, because it replace the colorization for all buffers, whatever the language is, this is for showing the case.

events.connect(events.STYLE_NEEDED, function(end_pos, buffer)
   local style_index = buffer:style_of_name("default")
   if end_pos >= 1 and buffer ~= nil then
      buffer:start_styling(1, 0)
      buffer:set_styling(end_pos - 1, style_index)
      return true  -- Anything not nil
   end
end, 1)

Then, close Textadept and restart it to open a long enough, preferably as a text file, like about 5000 lines. Ex. a big Lua source file or appended multiple times to a file, with .txt extension. The number may depends on the speed of your CPU. For me, 2000 lines is enough, which is not recommended for a source file, while which is not that uncommon.

From the top of the file, scroll down line by line with the down arrow key of your keyboard always pressed. It should be OK. Now, go at the end of the file, ex with Ctrl+End. Then, scroll up with the up arrow key always pressed. It is anomalously not enough responsive.

It is with Textadept 13, a nightly build on Linux, with both the QT and GTK version, I can’t tell if it is the same on Mac and Windows.

Then in the snippet above, change "default" into "whitespace.text". Do the same, closing text adept, opening the file and etc. Now, it is perfectly responsive.

I though it was the styling, but if I give the "whitespace.text" style tag the same style as for keyword, it is still OK, while if I use "keyword" instead of "whitespace.text", then it is unresponsive. It seems to not be the styling, just the style index and the issue happens while there is no colorization because Textadept does not trigger colorization request during scrolling.

How to explain this?

Edit: I suspect the issue comes from Scintilla, not Textadept, because Textadept does not seem to handle scrolling, while I may be wrong.

[orbitalquark]

I'm not exactly sure what's going on, but you are restyling the entire buffer on each STYLE_NEEDED event. buffer:start_styling() should probably accept buffer.end_styled as a first argument, not 1 (the beginning of the buffer). Perhaps restyling the entire document again and again is affecting Scintilla's internal state, redraw routines, etc. in an unintended way.

[Hibou57]

you are restyling the entire buffer on each STYLE_NEEDED event. buffer:start_styling() should probably accept buffer.end_styled as a first argument, not 1

Yes, it was to simplify, but the origin is not there. I did not say I discovered this when trying to find the relevant difference between my colorization procedure and the native one of Textadept. I did this disabling some part of it, step by step, to inspect the result. I finally notice this: if on the line

textadept/core/lexer.lua

Line 130 in 2516092

set_styling(buffer, e - pos, tags[styles[i]] or view.STYLE_DEFAULT) -- support legacy lexers

I changed tags[styles[i]] or view.STYLE_DEFAULT into just view.STYLE_DEFAULT then it was the most minimal condition to have the same effect. So I inspected the style passing in styles[i] and noticed a “whitespace.text”. The presence of this style was enough to retrieve smooth scrolling even in the presence of some view.STYLE_DEFAULT. It happens I used “default” for white-space so I changed it to “whitespace.text”. Aside, I noticed if I do it when colorizing Lua files, then the menu Tools->Show-style says it is whitespace_lua instead of whitespace_text.

If there are some “whitespace.text” in the colorized text, it’s OK, if there are only others styles, it’s not OK. But I’m note sure “whitespace.text” is the only one, just the only one I noticed.

If my mind is not wrong, I feel to remember using automatic line-wrapping on a text file with long lines, make scrolling far less responsive too. I was not using automatic line-wrapping for these tests, but may be Scintilla is doing some related or similar scanning when scrolling, even without line-wrap. At least, it would explain why the “whitespace.text” has a good effect on scrolling. Still remains that the simple “whitespace” style does not have the same good effect.

I should check if “whitespace.text” is a style Scintilla knows natively.

I wanted to do some more precise tests, on the amount of “whitespace.text” needed for smooth scrolling, but have not yet.

Thanks for your response

[orbitalquark]

I am having a hard time understanding what the issue is. The fact that you are making your own styling calls is most likely the cause of any slowdowns you are seeing. I find it hard to believe the presence of one style name over another is causing such a slowdown, unless tags[styles[i]] is returning nil (which it shouldn't if you are using a built-in lexer). Repeated lookup misses might cause a slowdown, but I doubt it.

As for "whitespace_text" vs "whitespace_lua", the lexer appends the lexer name to the end of "whitespace_". If you pick the "text" lexer, you'll see "whitespace_text". If you pick the "lua" lexer, you'll see "whitespace_lua". The Lua lexer will not have "whitespace_text" defined, nor will the text lexer have "whitespace_lua" defined. Perhaps this was obvious and I'm misunderstanding the confusion (if any) around these styles.

[Hibou57]

The fact that you are making your own styling calls is most likely the cause of any slowdowns you are seeing.

Just checked it is not. Disabled everything to check and the strange behavior is still there.