Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Shift+Down arrow key selection is jerky in the new CEF used in sprint 30. #4862

Closed
RaymondLim opened this issue Aug 21, 2013 · 13 comments
Closed
Assignees

Comments

@RaymondLim
Copy link
Contributor

  1. Open a js file that has lines more than one screen.
  2. Set the cursor at the beginning of one line.
  3. Hold Shift key down and press Down arrow key to select multiple lines and watch the highlighted lines.

Result: Selection may pause and then a sudden jump to highlight a block of lines. If you try the same steps in sprint 29 build, you don't see the sudden jumps as you hold down Down arrow key.

@RaymondLim
Copy link
Contributor Author

You can also see the jerky cursor movement if you just hold down Down arrow key without the Shift key. But it is easier to see the jerky effect with selection.

@lkcampbell
Copy link
Contributor

@RaymondLim, this isn't just a Mac only problem. I have this problem on Windows 7.

In particular, the Highlight Active Line option makes repetitive up and down arrow movements (i.e. holding the arrow key down for a period of time) very jerky, almost unusable. This happens when I use the up or down arrow keys by themselves and it is significant enough that I have to turn off Highlight Active Line in order to properly use my editor.

As a contrast, Sprint 29 up and down arrows (with or without shift) navigate very smoothly even when Highlight Active Line is on.

@gruehle
Copy link
Member

gruehle commented Aug 26, 2013

Reviewed. Removed "Mac only" label, medium priority to @JeffryBooher

@njx
Copy link
Contributor

njx commented Aug 29, 2013

Nominating for sprint 31. FWIW, I didn't see this on the Mac when I tried it yesterday, but I do recall seeing it before. Not sure what would have changed.

@ghost ghost assigned redmunds Sep 4, 2013
@peterflynn
Copy link
Member

I'm not seeing this on Windows either -- whether using only arrows, arrows with highlight line, or shift+arrows. I see an occasional stutter every few seconds. Nothing like the description above...

On my ancient 10.6 first-gen Mactel MBP, however, performance is unusably bad even with plain arrows and no highlight -- often taking more than 2 seconds per frame when cursor movement is causing scrolling.

I think the long & short of this is that newer Chromes make our performance much more GPU-dependent.

Has anyone tried doing the same tests in browser (first resizing CodeMirror to similar pixel size as a Brackets window) -- especially in a matching version, i.e. Chrome 29. If we don't see similar issues there, then there may be hope for us yet...

@RaymondLim
Copy link
Contributor Author

Actually, I'm not seeing the issue anymore. Maybe it's just a perception due to my initial testing with Highlight Active Line on. Now, even with the Highlight Active Line on I can hardly tell the jerkiness. There is still some slight jerkiness when both Highlight Active Line and Word Wrap are on and you move the cursor across the wrapped lines. Again, this may be due to perception as the highlight of wrapped lines to/fro non-wrapped line has noticeablly different sizes.

@redmunds
Copy link
Contributor

redmunds commented Sep 5, 2013

With Highlight Active Line turned off, scrolling page with up/down keys (with or without Shift key down) seems ok to me. On Windows, it's a little faster and smoother if cursor is in column 0 as opposed to middle of the page (where there are some subtle jerks). On Mac, scrolling is noticeably slower, which (for better or worse) is perceived as smoother.

Turning on Highlight Active Line, makes this an order of magnitude worse, so it seems like #4778 is a much higher priority than this one.

@redmunds
Copy link
Contributor

redmunds commented Sep 6, 2013

Closing.

@redmunds redmunds closed this as completed Sep 6, 2013
@lkcampbell
Copy link
Contributor

@redmunds, I understand why you are closing this issue if no one else is having the problem. I still see it, however, and would like to keep investigating it. Maybe it is because I have an older Windows 7 laptop, not sure. At any rate, these are the timeline profiles I get when doing a small shift-arrow selection, 20 lines or so, holding down the keys. The first is with Sprint 29 and the second is with the latest Dev version (let's just call it Sprint 30):

sprint-29-capture

sprint-30-capture

These two profiles look different to me but I don't know enough about the timeline tool to interpret them. Can you tell me roughly what is the difference between these two profiles and what might be causing it? Or if not, what further information I need to collect?

@redmunds
Copy link
Contributor

redmunds commented Sep 6, 2013

OK. Re-opening. Removing Milestone.

@redmunds redmunds reopened this Sep 6, 2013
@ghost ghost assigned lkcampbell Sep 6, 2013
@lkcampbell
Copy link
Contributor

If I remove all of my extensions, I can make this issue go away for me. Didn't have the problem with all of my extensions in Sprint 29. It seems to mostly be caused by a combination of extensions: a good portion from Themes extension, a bit from Indent Guides, perhaps a bit from Column Ruler, not sure.

The worst offender appears to be Show Whitespace. When it is turned on, the performance is as bad (if not worse) as Highlight Active Line. This tells me that the Code Mirror overlay support may not work as efficiently in Sprint 30 as it did in Sprint 29. Or maybe, more generally, all of the span style changes that Code Mirror is creating are causing some performance problems.

In summary, I am closing this bug since it appears to be caused by extensions. As @redmunds pointed out earlier, investigating the cause of issues #4778 and #5000 should be done next. Perhaps if we can figure out why the Highlight Active Line style is causing these performance problems, we may also be able to address the extension styling problems contributing to this issue as well.

@njx
Copy link
Contributor

njx commented Sep 6, 2013

Thanks for tracking this down. I think the performance of Show Whitespace has always been a bit of an issue. Might be worth filing an issue in the repo for that extension noting that it seems to have gotten worse with the latest shell.

@lkcampbell
Copy link
Contributor

You know, it's strange. Even with all of my extensions loaded, I don't see this problem any more in the new install of the Sprint 30; however, I had it all through the dev build leading up through Sprint 30, and I still have it now in my Dev build for Sprint 31 as well.

It will be interesting to see if I have the problem in the new Sprint 31 install once it becomes available. I just can't think of why the dev build version would cause these navigation and selection problems for me though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants