Render lines via tiles #6733

Merged
merged 68 commits into from Jun 2, 2015

Conversation

Projects
None yet
@as-cii
Member

as-cii commented May 11, 2015

This PR introduces a change in how we render lines. It does so by organizing them into tiles, which we then move up and down through a compositing transformation. The main advantage is that paint times dramatically reduce, because now we simply need to paint a small tile, instead of all the lines. This is especially noticeable during scrolling which, as a result, will be the subject of the benchmarks I am going to show later on.

Please, note that:

  • Specs are broken. The solution you can see here was achieved by spiking a bunch of ideas, and therefore I didn't pay attention to change specs/code gradually. As a result, I plan to adapt previous specs and write some new ones as soon as possible.
  • There's some evident structural duplication in code. However, I'd like to start refactoring that stuff as soon as I have unit tests to prevent naive errors.
  • Naming-wise I am not entirely happy with TilesPresenter and LinesPresenter and they're probably going to change. Any suggestion or improvement is very welcome here.
  • I have intentionally left out line numbers from using this new approach. I'd like to keep this PR focused and work on that right after 馃殺ping this one.

馃悗 And now some benchmarks! 馃悗

Benchmarks

Tests conducted using:

  • A 1920x1080 window

  • editor.scrollSensitivity = 130

  • A custom code (associated to a keyboard key) to simulate mouseWheel events

    document.querySelector("html /deep/ .editor-contents--private").dispatchEvent(new WheelEvent("mousewheel", wheelDeltaY: -250))
  • Keyboard Key Repeat: Fast (Mac OS X setting)

  • Delay Until Repeat: Short (Mac OS X setting)

I needed a (more or less) repeatable way to benchmark scrolling. To try this out, you can simply scroll up and down as you would normally do.

master

master

as-tiled-rendering

as-tiled-rendering

Why this matters?

As you can notice, paint times are dramatically reduced. This may not be noticeable with your 馃憖, but it's nevertheless important 'cause it leaves some room for additional operations (such as a more expensive character measurement computation). As said earlier, things are going to speed up further once we introduce tiling for line numbers as well.

It would be great if you could try this out, reporting any eventual regression or glitch that I may have overlooked while implementing the tiling strategy. Moreover, any code review or additional 馃憖 are always welcome.

Thank you!

/cc: @atom/feedback @nathansobo

src/lines-presenter.coffee
@@ -0,0 +1,41 @@
+module.exports =
+class LinesPresenter

This comment has been minimized.

@as-cii

as-cii May 11, 2015

Member

This should really be TilePresenter.

@as-cii

as-cii May 11, 2015

Member

This should really be TilePresenter.

@maxbrunsfeld

This comment has been minimized.

Show comment
Hide comment
@maxbrunsfeld

maxbrunsfeld May 11, 2015

Contributor

Really exciting work.

Contributor

maxbrunsfeld commented May 11, 2015

Really exciting work.

src/text-editor-presenter.coffee
@@ -963,7 +963,7 @@ class TextEditorPresenter
hasPixelPositionRequirements: ->
@lineHeight? and @baseCharacterWidth?
- pixelPositionForScreenPosition: (screenPosition, clip=true) ->
+ pixelPositionForScreenPosition: (screenPosition, clip=true, {absolute}={}) ->

This comment has been minimized.

@nathansobo

nathansobo May 11, 2015

Contributor

Talk to me a little about this absolute flag... seems like you should always just choose the position relative to the viewport now since the lines layer is no longer moving. Either way, I think we should avoid allocating the options object on this hot path. I'm paranoid about garbage objects these days.

@nathansobo

nathansobo May 11, 2015

Contributor

Talk to me a little about this absolute flag... seems like you should always just choose the position relative to the viewport now since the lines layer is no longer moving. Either way, I think we should avoid allocating the options object on this hot path. I'm paranoid about garbage objects these days.

src/text-editor-presenter.coffee
+
+ visibleTiles = {}
+ for index in [startIndex...endIndex]
+ presenter = @linesPresentersByTileIndex[index] ?= new LinesPresenter(@)

This comment has been minimized.

@nathansobo

nathansobo May 11, 2015

Contributor

Is it too nasty to just build out the tile in a subroutine of the current presenter?

@nathansobo

nathansobo May 11, 2015

Contributor

Is it too nasty to just build out the tile in a subroutine of the current presenter?

This comment has been minimized.

@as-cii

as-cii May 13, 2015

Member

I have inlined it for the time being 馃敟

The main idea with having a separate object, though, was to push the design of presenters/components in another direction. This object, as it is right now, tends to couple different behaviors in the same place and I can feel a lot of cognitive overhead every time I add new features or fix 馃悰s (e.g. when I change how lines construction behave I have to think about the details of how cursors work, and vice versa).

馃挕 By separating each responsibility, I think we could be able to understand each presenter at a glance and, as a result, feel more confident to change it.

Probably I have been a bit too abstract here, but I'd love to hear your opinion about moving towards more cohesive presenters in the future 馃挱

@as-cii

as-cii May 13, 2015

Member

I have inlined it for the time being 馃敟

The main idea with having a separate object, though, was to push the design of presenters/components in another direction. This object, as it is right now, tends to couple different behaviors in the same place and I can feel a lot of cognitive overhead every time I add new features or fix 馃悰s (e.g. when I change how lines construction behave I have to think about the details of how cursors work, and vice versa).

馃挕 By separating each responsibility, I think we could be able to understand each presenter at a glance and, as a result, feel more confident to change it.

Probably I have been a bit too abstract here, but I'd love to hear your opinion about moving towards more cohesive presenters in the future 馃挱

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo May 11, 2015

Contributor

I've been talking about wanting to do tiles for a year now. Thanks so much for pushing this forward!

Contributor

nathansobo commented May 11, 2015

I've been talking about wanting to do tiles for a year now. Thanks so much for pushing this forward!

@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle May 11, 2015

Contributor

Wow, looks like a huge speedup

Contributor

benogle commented May 11, 2015

Wow, looks like a huge speedup

@Zireael07

This comment has been minimized.

Show comment
Hide comment
@Zireael07

Zireael07 May 12, 2015

Always good to see speedups!

Always good to see speedups!

Relativize `pixelPositionForScreenPosition`.`top`
This commit makes the method return a `top` value which is relative to the
viewport. However, we still need to return an absolute value for `left` because
lines are moved horizontally through a single transform on their parent node.

I would prefer being consistent (i.e. make everything relative), but moving
every single tile to simulate scrolling, on the other hand, seems overkill and
it's not really intuitive given that we are not tiling horizontally.

/cc: @nathansobo
@as-cii

This comment has been minimized.

Show comment
Hide comment
@as-cii

as-cii May 13, 2015

Member

Talk to me a little about this absolute flag... seems like you should always just choose the position relative to the viewport now since the lines layer is no longer moving.

As explained on this commit I got rid of the absolute flag, but I am not happy with the inconsistent result of @pixelPositionForScreenPosition: top returns a relative value, whereas left is still computed as an absolute value. That's because as of now, in order to scroll horizontally, we simply apply an horizontal transform on the container node.

To make things more consistent we have two options:

  • Simulate horizontal scrolling by moving each tile as we do for vertical scrolling. I have experimented with this and I don't find this to be particularly intuitive, as there is no real reason for moving tiles one by one for such scenario.
  • Put lines in a separate container. The way in which we position lines shouldn't affect how other components are rendered.

I see the latter as the most natural approach but I may be overlooking/underestimating something. @nathansobo: what do you think?

Member

as-cii commented on 19a9565 May 13, 2015

Talk to me a little about this absolute flag... seems like you should always just choose the position relative to the viewport now since the lines layer is no longer moving.

As explained on this commit I got rid of the absolute flag, but I am not happy with the inconsistent result of @pixelPositionForScreenPosition: top returns a relative value, whereas left is still computed as an absolute value. That's because as of now, in order to scroll horizontally, we simply apply an horizontal transform on the container node.

To make things more consistent we have two options:

  • Simulate horizontal scrolling by moving each tile as we do for vertical scrolling. I have experimented with this and I don't find this to be particularly intuitive, as there is no real reason for moving tiles one by one for such scenario.
  • Put lines in a separate container. The way in which we position lines shouldn't affect how other components are rendered.

I see the latter as the most natural approach but I may be overlooking/underestimating something. @nathansobo: what do you think?

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo May 13, 2015

Contributor

@as-cii I think it's fine to position tiles both vertically and horizontally. If we're already positioning every tile on the GPU vertically, doing so horizontally doesn't seem like a huge stretch. I get that it isn't strictly needed because we aren't tiling horizontally, but I also think it's the most consistent approach. We move from a world where the entire content plane was moved to a world in which the content is fragmented into tiles, each which move.

One thing to watch out for is that this has implications for overlay decorations as well. They are currently absolutely positioned relative to the big lines layer, and so move automatically when it moves. Now they will need to be explicitly moved along with the tiles when they scroll. Treating both horizontal and vertical dimensions the same way just seems the simplest to me. We don't need to conceptualize the different dimensions differently.

Contributor

nathansobo replied May 13, 2015

@as-cii I think it's fine to position tiles both vertically and horizontally. If we're already positioning every tile on the GPU vertically, doing so horizontally doesn't seem like a huge stretch. I get that it isn't strictly needed because we aren't tiling horizontally, but I also think it's the most consistent approach. We move from a world where the entire content plane was moved to a world in which the content is fragmented into tiles, each which move.

One thing to watch out for is that this has implications for overlay decorations as well. They are currently absolutely positioned relative to the big lines layer, and so move automatically when it moves. Now they will need to be explicitly moved along with the tiles when they scroll. Treating both horizontal and vertical dimensions the same way just seems the simplest to me. We don't need to conceptualize the different dimensions differently.

spec/text-editor-presenter-spec.coffee
- expect(lineStateForScreenRow(presenter, 9)).toBeUndefined()
-
- it "does not overdraw above the first row", ->

This comment has been minimized.

@as-cii

as-cii May 13, 2015

Member

@nathansobo: is line-overdrawing strictly a performance "feature"? Overdrawing tiles doesn't seem to provide any significant speedup and, therefore, I simply got rid of them. What do you think?

@as-cii

as-cii May 13, 2015

Member

@nathansobo: is line-overdrawing strictly a performance "feature"? Overdrawing tiles doesn't seem to provide any significant speedup and, therefore, I simply got rid of them. What do you think?

This comment has been minimized.

@nathansobo

nathansobo May 13, 2015

Contributor

You're correct to drop it with tiling. It used to be required to prevent a full screen repaint when adding/removing lines at the top/bottom. If the repainted regions were too close together they would be grouped. This approach bypasses all such nonsense.

@nathansobo

nathansobo May 13, 2015

Contributor

You're correct to drop it with tiling. It used to be required to prevent a full screen repaint when adding/removing lines at the top/bottom. If the repainted regions were too close together they would be grouped. This approach bypasses all such nonsense.

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo May 29, 2015

Contributor

@atom/feedback Can anyone test this on Windows and Linux (without a VM)? I want to make sure there are no performance regressions on those platforms. It seems unlikely, but there may be difference in the GPU compositing pipeline and I just want to make sure before putting this on master.

Contributor

nathansobo commented May 29, 2015

@atom/feedback Can anyone test this on Windows and Linux (without a VM)? I want to make sure there are no performance regressions on those platforms. It seems unlikely, but there may be difference in the GPU compositing pipeline and I just want to make sure before putting this on master.

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov May 30, 2015

Tested here #6733 (comment), on Ubuntu 14.04, was great!

Tested here #6733 (comment), on Ubuntu 14.04, was great!

- unless @measuredLines.has(id)
- lineNode = @lineNodesByLineId[id]
- @measureCharactersInLine(id, lineState, lineNode)
- return

This comment has been minimized.

@kevinsawicki

kevinsawicki Jun 1, 2015

Member

Should this return be retained so that the results of the for loop aren't built up in an array and returned?

@kevinsawicki

kevinsawicki Jun 1, 2015

Member

Should this return be retained so that the results of the for loop aren't built up in an array and returned?

This comment has been minimized.

@kevinsawicki

kevinsawicki Jun 1, 2015

Member

Nevermind, looks like it is, just way down in the diff, sorry.

@kevinsawicki

kevinsawicki Jun 1, 2015

Member

Nevermind, looks like it is, just way down in the diff, sorry.

This comment has been minimized.

@as-cii

as-cii Jun 2, 2015

Member

No worries about that. I am actually sorry this diff got so ugly 馃檹

@as-cii

as-cii Jun 2, 2015

Member

No worries about that. I am actually sorry this diff got so ugly 馃檹

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Jun 2, 2015

Contributor

Tested on Windows and it's working correctly.

Contributor

nathansobo commented Jun 2, 2015

Tested on Windows and it's working correctly.

nathansobo added a commit that referenced this pull request Jun 2, 2015

@nathansobo nathansobo merged commit dac39bd into master Jun 2, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@nathansobo nathansobo deleted the as-tiled-rendering branch Jun 2, 2015

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Jun 2, 2015

Contributor

Thanks very much @as-cii. People are really going to be happy to see scroll speed improvements.

Contributor

nathansobo commented Jun 2, 2015

Thanks very much @as-cii. People are really going to be happy to see scroll speed improvements.

@alexandernst

This comment has been minimized.

Show comment
Hide comment
@alexandernst

alexandernst Jun 2, 2015

Let's see if this helps with my #6981

Let's see if this helps with my #6981

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 3, 2015

@nathansobo @as-cii i am testing on linux 64bit.
I opened up a compiled js file , with long lines and 1.2MB.
Selection is smooth, editing is a bit laggy
Scrolling is fine until it goes to bottom.

When scrolled to bottom part , it freeze up , taking 100% CPU and seems to be generating tiles, for 20-40 secs?
That bottom part is 1.1 mil chars , within 2 lines only.
It happens everytime when scroll back to top and bottom part again

Is it possible to move tiles generation to a worker process? I have tested with 205 and it rendered fast and fine.

v3ss0n commented Jun 3, 2015

@nathansobo @as-cii i am testing on linux 64bit.
I opened up a compiled js file , with long lines and 1.2MB.
Selection is smooth, editing is a bit laggy
Scrolling is fine until it goes to bottom.

When scrolled to bottom part , it freeze up , taking 100% CPU and seems to be generating tiles, for 20-40 secs?
That bottom part is 1.1 mil chars , within 2 lines only.
It happens everytime when scroll back to top and bottom part again

Is it possible to move tiles generation to a worker process? I have tested with 205 and it rendered fast and fine.

@as-cii

This comment has been minimized.

Show comment
Hide comment
@as-cii

as-cii Jun 3, 2015

Member

Hi @v3ss0n, thank you for your feedback!

Could you please attach somewhere the file you're talking about? If it's private and you don't want to share it with everyone, it'd be awesome if you could share it via e-mail (you can find my address on my profile, https://github.com/as-cii).

Thanks a lot!

Member

as-cii commented Jun 3, 2015

Hi @v3ss0n, thank you for your feedback!

Could you please attach somewhere the file you're talking about? If it's private and you don't want to share it with everyone, it'd be awesome if you could share it via e-mail (you can find my address on my profile, https://github.com/as-cii).

Thanks a lot!

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 3, 2015

@as-cii thanks a lot for fast response. I restarted atom and reopened, first it stop responding while atom start , and loading the file , so i start from scratch (previously auto reload have a lot of tabs and split panes opened ). Now it rendering fine . I tested without --safe.

So only problem remain is when previous session restored , and large files are opened previously atom stop responding and has to force close (can reproduce with --safe )

Rendering is smooth and fine , i copy / paste that file 10 times , making 11mb , and it dosen't slow down scrolling at all!

Thanks a lot for hard work , i will upload the file i testing to gist in a bit.

v3ss0n commented Jun 3, 2015

@as-cii thanks a lot for fast response. I restarted atom and reopened, first it stop responding while atom start , and loading the file , so i start from scratch (previously auto reload have a lot of tabs and split panes opened ). Now it rendering fine . I tested without --safe.

So only problem remain is when previous session restored , and large files are opened previously atom stop responding and has to force close (can reproduce with --safe )

Rendering is smooth and fine , i copy / paste that file 10 times , making 11mb , and it dosen't slow down scrolling at all!

Thanks a lot for hard work , i will upload the file i testing to gist in a bit.

@maxbrunsfeld maxbrunsfeld referenced this pull request Jun 3, 2015

Closed

Find remaining performance bottlenecks for large files #6692

17 of 20 tasks complete
@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 3, 2015

Here are things i've tested so far:

###Works

  • 11 MB file
  • More than 100k char per line
  • Compiled Javascript file (with a lot of tokens )
  • Just characters
  • Select word , Select Line , Select Multiple line , Select all

##Fails

  • Reopen session with many tabs and one huge file.

v3ss0n commented Jun 3, 2015

Here are things i've tested so far:

###Works

  • 11 MB file
  • More than 100k char per line
  • Compiled Javascript file (with a lot of tokens )
  • Just characters
  • Select word , Select Line , Select Multiple line , Select all

##Fails

  • Reopen session with many tabs and one huge file.
@alexandernst

This comment has been minimized.

Show comment
Hide comment
@alexandernst

alexandernst Jun 9, 2015

This looks very interesting nodejs/node#1159
I wonder if Atom could use it for heavy tasks? @nathansobo

This looks very interesting nodejs/node#1159
I wonder if Atom could use it for heavy tasks? @nathansobo

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Jun 9, 2015

Contributor

@alexandernst That looks super interesting. Thanks for the heads up.

Contributor

nathansobo commented Jun 9, 2015

@alexandernst That looks super interesting. Thanks for the heads up.

@ilanbiala

This comment has been minimized.

Show comment
Hide comment
@ilanbiala

ilanbiala Jun 10, 2015

@nathansobo does Atom already use io.js or is it still on Node?

@nathansobo does Atom already use io.js or is it still on Node?

@mnquintana

This comment has been minimized.

Show comment
Hide comment
@mnquintana

mnquintana Jun 10, 2015

Member

@ilanbiala Atom uses io.js 鈥 Electron uses it.

Member

mnquintana commented Jun 10, 2015

@ilanbiala Atom uses io.js 鈥 Electron uses it.

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Jun 10, 2015

Contributor

@ilanbiala Yep. It could take a while for this feature to get to us however since it's not even merged to master in iojs. Then it has to be released in an official iojs release, integrated into Electron, and finally Atom has to upgrade to that version of Electron. But definitely worth keeping an eye on. It's something we could definitely make lots use of once it's available.

Contributor

nathansobo commented Jun 10, 2015

@ilanbiala Yep. It could take a while for this feature to get to us however since it's not even merged to master in iojs. Then it has to be released in an official iojs release, integrated into Electron, and finally Atom has to upgrade to that version of Electron. But definitely worth keeping an eye on. It's something we could definitely make lots use of once it's available.

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 10, 2015

This may be a bit offtopic but curious.
@mnquintana atom is built using node 0.12 on my machine , is that already using IO.js ?
Atom current version is not using electron , yet right?

v3ss0n commented Jun 10, 2015

This may be a bit offtopic but curious.
@mnquintana atom is built using node 0.12 on my machine , is that already using IO.js ?
Atom current version is not using electron , yet right?

@mehcode

This comment has been minimized.

Show comment
Hide comment
@mehcode

mehcode Jun 10, 2015

Contributor

@v3ss0n From what I understand atom has a packaged version. The version you have is only used to bootstrap the process.

Contributor

mehcode commented Jun 10, 2015

@v3ss0n From what I understand atom has a packaged version. The version you have is only used to bootstrap the process.

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov Jun 10, 2015

@v3ss0n it is currently io v1.6.3 and being updated to io v2.2.1

@v3ss0n it is currently io v1.6.3 and being updated to io v2.2.1

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 10, 2015

ah i got it , it have packaged own IO.js separated from OS version ?

v3ss0n commented Jun 10, 2015

ah i got it , it have packaged own IO.js separated from OS version ?

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 11, 2015

We have a problem with tile rendering , effecting themes with background transparency : https://github.com/v3ss0n/steam-pirate-ui
It renders tiles in more darkened color than my theme's color , i had compared it against atom version without tiled rendering. See attached. The text area part of the editor is darkened vs the bottom part (the actual theme's color)

tile_rendering_theme

from styling side , should i theme .lines or .tile

v3ss0n commented Jun 11, 2015

We have a problem with tile rendering , effecting themes with background transparency : https://github.com/v3ss0n/steam-pirate-ui
It renders tiles in more darkened color than my theme's color , i had compared it against atom version without tiled rendering. See attached. The text area part of the editor is darkened vs the bottom part (the actual theme's color)

tile_rendering_theme

from styling side , should i theme .lines or .tile

@olmokramer

This comment has been minimized.

Show comment
Hide comment
@olmokramer

olmokramer Jun 21, 2015

Hey, awesome work on the tile rendering! I've got one problem with it, however, as it breaks my block-cursor package.

To have a block-cursor, I used to add a (opaque) background color to the cursor element, and set its z-index to -1. That way, the cursor would render behind the text, and text would still be legible.

Now, with the new tile rendering, all the lines are inside a new element with an opaque background, so I can't render the cursor behind the lines anymore (or it would also be behind the tile, and thus invisible anyway)...

There's the option to set a very low alpha value on the cursor color, and render it in front of the text, but that way the cursor changes the text color, and it's tricky to find a value that produces a nice color and keeps text legible.

Hey, awesome work on the tile rendering! I've got one problem with it, however, as it breaks my block-cursor package.

To have a block-cursor, I used to add a (opaque) background color to the cursor element, and set its z-index to -1. That way, the cursor would render behind the text, and text would still be legible.

Now, with the new tile rendering, all the lines are inside a new element with an opaque background, so I can't render the cursor behind the lines anymore (or it would also be behind the tile, and thus invisible anyway)...

There's the option to set a very low alpha value on the cursor color, and render it in front of the text, but that way the cursor changes the text color, and it's tricky to find a value that produces a nice color and keeps text legible.

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 21, 2015

it seems we have no choice but to embrace it ? The benefits outweighs a few styling inflexibility , but i miss my beautiful theme tho .

v3ss0n commented Jun 21, 2015

it seems we have no choice but to embrace it ? The benefits outweighs a few styling inflexibility , but i miss my beautiful theme tho .

@olmokramer

This comment has been minimized.

Show comment
Hide comment
@olmokramer

olmokramer Jun 21, 2015

Hmmm, I just thought that highlights might suffer from the same issue, but then I found that a highlights container is added to each tile. I wonder if this is also possible for the cursors, or would it be too much of a performance issue? Or just too much work for too little gain?

Hmmm, I just thought that highlights might suffer from the same issue, but then I found that a highlights container is added to each tile. I wonder if this is also possible for the cursors, or would it be too much of a performance issue? Or just too much work for too little gain?

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 21, 2015

Highlights? the Highlight selected package ? or Editor's highlight? I am gonna give a try. I was too busy these days and haven't hack atom much last 2-3 weeks.

v3ss0n commented Jun 21, 2015

Highlights? the Highlight selected package ? or Editor's highlight? I am gonna give a try. I was too busy these days and haven't hack atom much last 2-3 weeks.

@as-cii

This comment has been minimized.

Show comment
Hide comment
@as-cii

as-cii Jun 22, 2015

Member

Hmmm, I just thought that highlights might suffer from the same issue, but then I found that a highlights container is added to each tile. I wonder if this is also possible for the cursors, or would it be too much of a performance issue? Or just too much work for too little gain?

Given that tiles have an opaque background, I am afraid this is the only possible solution. Moreover, that would be consistent with how we handle highlights, as you鈥檙e pointing out. I kinda overlooked it because Atom鈥檚 default cursor works just fine as it stands in front of the tiles; the implementation will definitely bring some complexity but, ultimately, I think it鈥檚 the right way of doing it and, after all, it won鈥檛 mess things up that much.

@olmokramer: that said, what do you think about opening a brand new issue where we can keep track of this? I plan to work on it, but I鈥檒l be traveling over the next days and I think I鈥檒l be able to tackle it starting from the next month.

Highlights? the Highlight selected package ? or Editor's highlight? I am gonna give a try. I was too busy these days and haven't hack atom much last 2-3 weeks.

@v3ss0n: highlights are an abstraction useful to decorate markers; you can have a look at the related blog post for all the nitty-gritty details.

Member

as-cii commented Jun 22, 2015

Hmmm, I just thought that highlights might suffer from the same issue, but then I found that a highlights container is added to each tile. I wonder if this is also possible for the cursors, or would it be too much of a performance issue? Or just too much work for too little gain?

Given that tiles have an opaque background, I am afraid this is the only possible solution. Moreover, that would be consistent with how we handle highlights, as you鈥檙e pointing out. I kinda overlooked it because Atom鈥檚 default cursor works just fine as it stands in front of the tiles; the implementation will definitely bring some complexity but, ultimately, I think it鈥檚 the right way of doing it and, after all, it won鈥檛 mess things up that much.

@olmokramer: that said, what do you think about opening a brand new issue where we can keep track of this? I plan to work on it, but I鈥檒l be traveling over the next days and I think I鈥檒l be able to tackle it starting from the next month.

Highlights? the Highlight selected package ? or Editor's highlight? I am gonna give a try. I was too busy these days and haven't hack atom much last 2-3 weeks.

@v3ss0n: highlights are an abstraction useful to decorate markers; you can have a look at the related blog post for all the nitty-gritty details.

@v3ss0n

This comment has been minimized.

Show comment
Hide comment
@v3ss0n

v3ss0n Jun 22, 2015

Thanks , interesting , i will look into it.

v3ss0n commented Jun 22, 2015

Thanks , interesting , i will look into it.

@olmokramer

This comment has been minimized.

Show comment
Hide comment
@olmokramer

olmokramer Jun 22, 2015

@as-cii Thanks! That's truly awesome :) I'll submit a new issue in the evening.

@as-cii Thanks! That's truly awesome :) I'll submit a new issue in the evening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment