Highlight Active Line significantly slows down selection

[njx]

1. Ensure View > Highlight Active Line is off
2. Click in a document
3. Hold down Shift-Down Arrow (and let it repeat) to extend the selection and note how fast it is
4. Turn View > Highlight Active Line on
5. Repeat steps 2-3

Result: Selection extension is much slower with Highlight Active Line on. Other selection methods, like drag select, are more sluggish as well, but it's most obvious when you hold down Shift-Down/Up Arrow.

[njx]

To @RaymondLim, medium priority. @ingorichter noticed this as well.

[lkcampbell]

@RaymondLim, I tested my fix for #3191 on this bug as well. It appears to help, but have you also noticed that the current Dev build has much slower selection than Sprint 29? Try running this repro in Sprint 29. It is nice and smooth for me. When I try the same thing in the current build it is jerky. It feels slow even when highlight active line is turned off. I'm using Windows 7.

[RaymondLim]

@lkcampbell
You're right! I see the jerky selection on Mac when using shift down arrow keys even without highlight active line enabled in current CEF build, but not in sprint 29.

[lkcampbell]

@RaymondLim, my fix is available but it only makes the worst case scenario slightly better.

This isn't just a problem with selection, it is a problem with any cursor movement. Try doing a repeating set of regular down arrow keys with the Active Line Highlight on, then compare it to Sprint 29. I originally thought my fix was causing this performance problems because I added a cursorActivity handler, but these problems were there before my fix.

I haven't investigated thoroughly yet, but I wonder if we introduced some new, slow cursorActivity event handler recently, or maybe CodeMirror changed something. My best guess is that it is cursorActivity related.

[RaymondLim]

@lkcampbell
Thanks for pointing out that the slowness has to do with cursor movement. I also noticed that but it is easier to see the slowness with selection than watching the tiny cursor movement. And I'm also pretty sure that the culprit is in CEF and not CodeMirror or recent introduction of any cursor event handler in Brackets. I say so because when I tried to use Brackets 29 shell with the current Brackets master (with updated CodeMirror), I didn't see the slowness at all.

[njx]

@RaymondLim - could you open a separate bug for the cursor movement slowness? Thanks.

[peterflynn]

If it depends on brackets-shell and not the actual www content, then we can probably rule out cursorActivity handlers. We might be looking at something similar to the inexplicable frame-dropping we saw with cursor movement / selection on Windows way back with CEF 1... not fun.

Sprint 30's CEF changes the rendering pipeline a lot, so unfortunately this isn't super surprising. Sprint 30 adds GPU acceleration and threaded compositing, just like current desktop Chrome. So one question would be, if you resize an in-browser CodeMirror instance to a similar size does it show the same rendering performance problems?

[RaymondLim]

@njx the cursor movement slowness is logged as #4862. Maybe it's not an actual slowness, but the actual update of the cursor is not in the same interval and gives the impression of slowness.

[lkcampbell]

@njx and @RaymondLim, even thought this issue spawned several other issues, the original issue, as described above, should be addressed by the "hide highlight when editor has selection" fix that was merged above. So you can probably change this issue to FBNC.

[RaymondLim]

@lkcampbell - I agree with you. Even with the highlight active line on, it's now hard to notice the slowness. The only time I can feel the slowness is both Highlight Active Line and Word Wrap are on and the cursor is passing thru wrapped lines and non-wrapped lines.

So FBNC to @njx

[redmunds]

I am seeing the same problem without Shift key held down, and it doesn't sound like the "hide highlight when editor has selection" would fix this case.

[lkcampbell]

@redmunds, you are correct. The "left over" bug after the "hide highlight on selection" fix is merged is filed as issue #5000.

[njx]

Agreed, doesn't seem noticeable to me now. Closing.