WIP: Render editor content via a tiling strategy

[nathansobo]

To Do

• Give tiles opaque backgrounds
• Support mouse-wheel velocity scrolling over tiles
• Cursors
• Highlight decorations
• Support line decoration options
• Change batching strategy
  • Try to get scrolling smoother
  • Support < 16ms response time for typing and cursor movement
• Foldable indicators in gutter, computed in TokenizedBuffer
• Fix the component specs (much of the heavy lifting is in the presenter now)
• Fix overlayer shims
• Figure out what to do about the underlayer

Underlayer Deprecation

Opaque tiles improve performance, but they destroy the previous ability to attach absolutely-positioned elements to the underlayer and have things just work. Based on this search, the following packages access the .underlayer outlet on the editor. Checkboxes are for adding the necessary APIs and creating issues/PRs on the package repositories:

Could use highlight decorations instead:

• https://github.com/richrace/highlight-selected (Use decorations  Pulsar-Edit-Highlights/selected#17)
• https://github.com/mlitbk/column-overflow
• https://github.com/yujinakayama/atom-lint
• https://github.com/atom/bracket-matcher
• https://github.com/atom/spell-check

Could use highlight decorations if we allowed arbitrary style assignment:

• https://github.com/wonnage/highlight-css-color

Could potentially use highlight decorations if we added a fullHeight and fullWidth option:

• https://github.com/tony612/highlight-column
• https://github.com/jtanner/crosshairs
• https://github.com/richrace/highlight-line (Use decorations  Pulsar-Edit-Highlights/line#23)

Could attach to the overlayer instead:

• https://github.com/Problematic/omni-ruler
• https://github.com/atom/wrap-guide

Extend the old editor in unsupported ways that probably don't work with the new editor:

• https://github.com/anson0370/scroll-past-end
• https://github.com/mlitbk/center-screen

Background

I'll explain more as this develops, but I'm experimenting with a new rendering strategy for the editor that's yielding promising results on Chromium 36. I've tried this before and closed it, but things are going better on this newer rendering engine and a bit more maturity in the EditorComponent code. The current rendering strategy exhibits some pretty serious performance regression on Chromium 36, so some kind of optimization work is something of a blocker for shipping it.

Here's a look at the composited layer borders in orange.

Here's a promising timeline of scrolling around at moderate speed, showing we're meeting most of our frame times with room to spare at 60 FPS.

I'm also pretty close clearing 13ms frame times for cursor movement (which is what I have my key repeat rate set at so it's important to me) with a different strategy for requesting frames. I wish I could supply requestAnimationFrame with my desired frame time for a given request. For now I'm hoping a synchronous rendering strategy for certain operations will suffice.

You never really know until it's fully implemented, but this is promising. The gutter is disabled because it's not yet tiled, and the cursors and highlight decorations (responsible for selections, among other things) haven't been fully implemented yet. But I'm feeling pretty good.

[nathansobo]

Yes, that's the plan.

[tony612]

@nathansobo Hi, thanks for your work on this.

I'm working on refactoring my repo https://github.com/tony612/highlight-column to use highlight decoration, but overcame a problem: when my cursor is on first char in a line(which is a tab), my marker range is [{x, 0}, {x, 0}] which is considered as empty. So the highlight decoration won't be rendered.

I know it's because the token is atomic, so the column of end point of the range is set to 0. But is there a way to solve this? I just want to highlight the column the cursor is at.

And this is my code for creating and updating the marker and decoration:

    # create
    range = cursor.getScreenRange().copy()
    marker = editor.markScreenRange(range, {invalidate: "never"})
    decoration = editor.decorateMarker(marker, {type: 'highlight', class: "highlight-column"})

    # update
    range = cursor.getScreenRange().copy()
    marker.setScreenRange(range)

[nathansobo]

I'm not sure that the highlight decoration will help you because we don't currently support vertical columns like what's pictured in your screen shot. So you're going to have to use DOM manipulation for now and keep using the underlayer. We'll have to add a column decoration facility before we switch over to tiled rendering.

[tony612]

@nathansobo Got it. Thank you

[ilanbiala]

@nathansobo is there any update on performance/progress with tiling?

[nathansobo]

It hasn't even started yet and is going to be back-burnered for a while longer. Are you still experiencing really bad scroll performance? Some members of the Chrome team offered to look at native traces with us to help determine the best way to improve scrolling performance. In light of the opportunity to work with them, I'd like to gather more data before committing time to this. Working with large files is higher priority at this time regardless. If anyone is interested in getting a branch going that experiments with this approach and gathering timeline data, I think it could still be helpful.

[ilanbiala]

I have a file with a varying amount of lines but always greater than 5000, so it's pretty slow to scroll. The slow scrolling may also be a result of long lines, but I'm not too sure what specifically has the biggest effect.

[nathansobo]

@ilanbiala I think the problems with a file like that are probably due to the long lines, in which case tiling vertically won't really help. We need to break lines up horizontally as well as vertically.

[ilanbiala]

Is there anything in the works for horizontal tiling? What's the slow part with long lines, the rendering? Would breaking up each long line into an array of short lines make any difference?

[nathansobo]

The DOM can only handle so much data before performance degrades. We restrict content vertically, but horizontally is more sophisticated due to the presence of variable width characters and we haven't gotten to it yet. Work on our new document model in https://github.com/atom/text-document should pave the way for it. It would be even easier if text measurement DOM APIs I have heard rumored land sooner rather than later.

[nathansobo]

This is supplanted by #6733.