View Issue Details

IDProjectCategoryView StatusLast Update
0035854LazarusIDEpublic2019-07-31 23:15
ReporterJan SebosikAssigned ToMartin Friebe 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.0.3 (SVN)Product Buildr61485 
Target VersionFixed in Version 
Summary0035854: Unable to scroll text editor while doing column selection
DescriptionDear community,

did anybody else observed situation that while you want to highlight column of text while holding Alt+Shift+Up/Down the code editor does not follow cursor?

Greets,
  Jan
Steps To Reproducemark some text with SHIFT+Left/Right arrow, then while still holding SHIFT press and hold ALT key and scroll up/down past the visible part of code editor to make selection column
TagsNo tags attached.
Fixed in Revision61649
LazTarget2.2
WidgetsetWin32/Win64
Attached Files

Activities

Martin Friebe

2019-07-17 11:56

manager   ~0117279

It works fine for me.

"mark some text with SHIFT+Left/Right arrow, then while still holding SHIFT press and hold ALT key and scroll up/down past the visible part of code editor to make selection column"
This is all performed by keyboard? No action/scrolling using the mouse?

It could be caused by some setting in Tools > Options.
Please find your config dir, usually: C:\Users\USERNAME\AppData\Local\lazarus
And in it the file EditorOptions.xml
Please attach this file.

------------------------------
Or do you mean, while pressing Alt+Shift you are using the mouse-wheel to scroll? This indeed will not extend the selection.

Jan Sebosik

2019-07-17 19:09

reporter   ~0117285

While marking column of text without going past the visible text it works fine - there is no requirement for editor window to scroll.
But - once I try to make column that needs to extend beyond visible text, then it does not scroll text while still holding pressed Alt+Shift+Up/Down arrow.
Once I release Up/Down arrow then source editor redraws content and I see where I stopped holding arrow key.

Everything done by keyboard, no mouse involved.

editoroptions.xml (957 bytes)

Martin Friebe

2019-07-17 20:54

manager   ~0117286

Unfortunately I still cannot reproduce.
Sorry this are going to be lots of questions now. But since I have no idea what causes the Issue, I need to look for any clue.

--------------------------------------

I tested with 2.0.3 61485 as you, also with trunk and with released 2.0.2.
All Lazarus are 64 bit and on Win10. And build with fpc 3.0.4

What I do to test:
- I open a unit that has more lines than fit in the editor (e.g ide/sourceeditor.pp).
- I press and hold shift
- I press cursor-right once (that will select one char)
- I press and hold Alt (now Shift + Alt are down)
- I press repeatedly cursor-down
When I reach the last fully visible text line, the next cursor down does scroll the editor up by one line, while still extending the selection.

Are those the exact same steps you do?
At any time, the source-editor window is fully visible on the screen. I can see the source editors statusbar at the bottom, and the tabs on the top.

--------------------------------------

- You are on Win 10 ?
- 64 bit?
- any packages installed?
   If you use anchordocking (or other docking), can you try without? It did work with anchordocking for me, but still.
- fpc, which version? (though that is not likely to matter)
- IDE compiled with any optimization settings?

Anything else that may vary from a default install?

-------------------------------------
When you have the problem that the editor does not scroll, can you watch out and see if:
- While you do Shift-Alt-cursor_down, does the line number in the left corner of the status bar increase (as it should)?
- "does not scroll". Can you watch the scrollbar. Even if the text does not move. Does or Doesn't the scrollbar change?

And does your source-editor have a horizontal scrollbar? Or can you lower its width, until it has?

-------------------------------------
Please start the IDE with
  lazarus.exe --debug-log=C:\somelogfile.txt
To do so, edit the desktop shortcut. Or run from a cmd.exe terminal.

Once the IDE started, please reproduce the issue.
Then close the Issue, and upload the logfile.

Jan Sebosik

2019-07-17 22:21

reporter   ~0117287

Last edited: 2019-07-17 22:22

View 2 revisions

For better imagination I will provide video capture of window.

Platform: Windows 8.1 x64 with updates till June 2019.
Used fpcupdeluxe to compile:
  FPC 3.2.x-STABLE branch
  Lazarus 2.0-STABLE branch

It seems to me that thanks to Windows Filter Keys the situation is worse.
But even with disabled filter keys it happens (but as keyrate is not so fast, it is not so bad - but text is still steady while scrolling).

Line number does not increase while scrolling, and scrollbar on right side of the text editor still scrolls - but - as it stalls scrolling text, right scroll bar slows down its speed.

Please see attached video (mp4 format) - stalled text editor is visible on this recording.



2019-07-17 22-13-01.mp4 (1,092,487 bytes)

Martin Friebe

2019-07-17 23:09

manager   ~0117289

Last edited: 2019-07-17 23:14

View 2 revisions

I see.
So if you do NOT hold the cursor-up key, but instead press (and release) it once for each line, then it probably works.

If that is the case, then this behaviour can not be fixed (other than improving the overall processing speed of the editor).

So if this is the issue, then it can currently not be fixed.
------------------------------------

As far as I can see, what happens is that the keys press events (auto repeat at a fast rate) use all the processing time, and there is no time for repainting the editor.

The way the many applications (including the IDE, and all LCL apps) work is, that they give paint events the lowest priority. So as long as key press events are coming from the OS, the IDE will not (re-)paint the editor (or do any other graphical update).
If it finishes a keypress, before the next one arrives, then it will do the painting. During that paint a lot of keypresses get queued, so after that paint it takes a long time to the next paint.

I can see, that the "extra carets" are painted (thin vertical white line). They are force painted, even if other painting is delayed. So that speaks for this being a "not enough time for paint" issue.

Note the editor and painting only use a single thread. So multi core CPU do not help here. This is a question between:
- The single core speed of your CPU
- The speed of your graphics hardware
- The time the editor needs to process the keypress

The editor is (unfortunately) not the fastest in the list. But it is not that slow either.
Until a year ago, I have used that editor on a vista pc that was about 10 years old. And scrolling was ok (Though I do rarely (if ever) use block selection). So I still wonder what slows it down for you.

You already turned off the most time consuming part of the editor, which is the "overview gutter" on the right side (that would be shown right next to the scroll bar).

-------------
There may be one more thing you can do. Especially if normal scrolling (cursor up/down, without selection) works for you).
Go to Tools > Option > Editor > General
Disable the checkbox: "Enable multi caret for column selection"

If you do column selection, the editor also creates additional carets, maybe painting those consumes to much time....

--
   ONLY if you do NOT check above option "Enable multi caret for column selection"
If you do need the extra carets, you can try to compile the IDE with (Tools > Configure Build Lazarus)
  -dSynCaretNoHideInSroll
I do not recall what the issue was with/without this define. It looks like it may reduce painting exactly in the case that causes this issue here.
So maybe it can help.

--
   ONLY if you do NOT check above option "Enable multi caret for column selection"
Another thing you could try (not sure if that helps though):
Open and edit components\synedit\syneditpointclasses.pas
line 2999 depends on svn rev)

procedure TSynEditScreenCaretPainterInternal.Init;
begin
  {$IFDEF LCLWin32}
    FForcePaintEvents := False; ///// <<<<<<<<<<<<<< CHANGE TO TRUE
  {$ELSE}
    FForcePaintEvents := True;
  {$ENDIF}

This will add more work when painting, outside scrolling. But when scrolling with multi carets, this may help

Martin Friebe

2019-07-17 23:11

manager   ~0117290

Please check if my description fits your case.

If you can: Does a lower key repeat fix/reduce the issue ?

Jan Sebosik

2019-07-18 00:25

reporter   ~0117291

Dear Martin,

once I unchecked the option "Enable multi caret for column selection" in Tools > Option > Editor > General, problem is gone.
My CPU is Core i7-6700HQ - not the best one on the planet, but should be sufficient for code editing.
( maybe guys with Java / Electron IDEs will have different opinion :D ).

Thanks for all the help that you've provided.

Martin Friebe

2019-07-18 00:42

manager   ~0117292

Ok, there is nothing I can fix in the short term.

On the long term, it might be that the multi caret drawing can be optimized (i.e. they should probably not be force drawn during scrolling)

So I leave the issue open, but it is not sure if/when any work will be done. Or if such work would be sufficient to fix the issue.

Jan Sebosik

2019-07-18 01:09

reporter   ~0117293

May I kindly ask you if you know which part of Lazarus source code is responsible for drawing of multiline caret?

Martin Friebe

2019-07-18 02:01

manager   ~0117294

Sure, all in the folder components/SynEdit.

In unit components\synedit\syneditpointclasses.pas
class TSynEditScreenCaretPainterInternal

Also check in SynEdit.pp the function TCustomSynEdit.ScrollAfterTopLineChanged

On Windows, a process can draw outside the paint event. Using XOR paint, this reduces workload for SynEdit.
But it appears that the carets are painted, even if the scroll never happened. That is probably undesirable.

---
I am happy to assists with further info. But if you do not mind, could we discuss this on the forum or mail list? (If you mention synedit/multicaret, I will notice it).

Martin Friebe

2019-07-31 15:54

manager   ~0117525

Strange, now it suddenly happens on my PC too.
Something must have changed the timings to just tip it over.

Martin Friebe

2019-07-31 22:56

manager   ~0117530

Last edited: 2019-07-31 23:15

View 2 revisions

Ok, I committed a fix to trunk (wont go to fixes).

Please test and close if ok. (re-open otherwise)


Note:
There remains a small chance of the scrolling still freezing. Most of them when doing carte down / scroll up. In that case the lowest line needs to be painted after each scroll (since the lowest line scrolled in).
If at the same time the editor needs to repaint a line further up, then all lines in between are repainted. This could in theory already cause freezes without the carets. But with the carets it is even more likely.
This can happen if:
- the caret moves over an "end;", and the matching "begin" is highlighted (if that feature is active)
- the caret leaves a long procedure, and the top-line of the editor had the "top line hint" name of the procedure, which then needs to be removed.
- ... other similar highlights.

Additionally the carets (while no longer all of them are repainted) still need to be processed. e.g. find which one(s) scrolled in/out. The more carets there are, the more processing. I found that (on my pc) at around 300/400 in combination with begin/end pairs, the first issues can be noted. After a minimal pause (release the keys), it is possible to continue (with all the carets), and it will scroll. I tested up to 2000 carets.
This processing may still be subject to minor optimization. But some freezing may remain, depending on the overall feature mix that is enabled.
EDIT: done in 61650

Issue History

Date Modified Username Field Change
2019-07-17 10:43 Jan Sebosik New Issue
2019-07-17 11:56 Martin Friebe Assigned To => Martin Friebe
2019-07-17 11:56 Martin Friebe Status new => feedback
2019-07-17 11:56 Martin Friebe LazTarget => -
2019-07-17 11:56 Martin Friebe Note Added: 0117279
2019-07-17 19:09 Jan Sebosik File Added: editoroptions.xml
2019-07-17 19:09 Jan Sebosik Note Added: 0117285
2019-07-17 19:09 Jan Sebosik Status feedback => assigned
2019-07-17 20:54 Martin Friebe Status assigned => feedback
2019-07-17 20:54 Martin Friebe Note Added: 0117286
2019-07-17 22:21 Jan Sebosik File Added: 2019-07-17 22-13-01.mp4
2019-07-17 22:21 Jan Sebosik Note Added: 0117287
2019-07-17 22:21 Jan Sebosik Status feedback => assigned
2019-07-17 22:22 Jan Sebosik Note Edited: 0117287 View Revisions
2019-07-17 23:09 Martin Friebe Note Added: 0117289
2019-07-17 23:11 Martin Friebe Status assigned => feedback
2019-07-17 23:11 Martin Friebe Note Added: 0117290
2019-07-17 23:14 Martin Friebe Note Edited: 0117289 View Revisions
2019-07-18 00:25 Jan Sebosik Note Added: 0117291
2019-07-18 00:25 Jan Sebosik Status feedback => assigned
2019-07-18 00:42 Martin Friebe Note Added: 0117292
2019-07-18 01:09 Jan Sebosik Note Added: 0117293
2019-07-18 02:01 Martin Friebe Note Added: 0117294
2019-07-31 15:54 Martin Friebe Note Added: 0117525
2019-07-31 22:56 Martin Friebe Status assigned => resolved
2019-07-31 22:56 Martin Friebe Resolution open => fixed
2019-07-31 22:56 Martin Friebe Fixed in Revision => 61649
2019-07-31 22:56 Martin Friebe LazTarget - => 2.2
2019-07-31 22:56 Martin Friebe Widgetset Win32/Win64 => Win32/Win64
2019-07-31 22:56 Martin Friebe Note Added: 0117530
2019-07-31 23:15 Martin Friebe Note Edited: 0117530 View Revisions