WIP: Render editor content via a tiling strategy #3154
Conversation
Previously, I was trying to update everything with the same method. Now I'm performing updates that are specifically tailored to each type of operation on the model.
Basic line decorations are working, but we still need to handle special decoration options.
|
Yes, that's the plan. |
|
@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) |
|
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. |
|
@nathansobo Got it. Thank you |
kevinsawicki
force-pushed
the
master
branch
2 times, most recently
from
dd8eda3 to
d1ecafc
Compare
|
@nathansobo is there any update on performance/progress with tiling? |
|
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. |
|
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. |
|
@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. |
|
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? |
|
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. |
|
This is supplanted by #6733. |
To Do
TokenizedBufferUnderlayer 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
.underlayeroutlet on the editor. Checkboxes are for adding the necessary APIs and creating issues/PRs on the package repositories:Could use highlight decorations instead:
Could use highlight decorations if we allowed arbitrary style assignment:
Could potentially use highlight decorations if we added a
fullHeightandfullWidthoption:Could attach to the overlayer instead:
Extend the old editor in unsupported ways that probably don't work with the new editor:
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
EditorComponentcode. 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
requestAnimationFramewith 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.