Scroll performance / behavior

Scrolling in Atom is everything but like native.
The acceleration is faster than in a browser, and it doesn’t feel as responsive.


Not sure if it’s related, but I’ve noticed the same behavior in Chrome browsers when I try to install extensions that implement any sort of smooth scrolling on OS X to match Safari. It ends up having super high acceleration that I can’t seem to configure. Perhaps a Chromium thing in general?

I have to agree with you @supermarin. Scroll speed is about twice what I’d expect from a native app.

As for responsiveness, yeah looking at the FPS meter while scrolling it regularly drops below 60, averaging 27FPS. pretty poor for a text editor, but its early days I suppose.


I sent some feedback about this too. It’s way too fast when scrolling.

1 Like

For now, this has put me off using it. Other than that, seems very nice and has most things I use.

Agreed that’s my number 1 complaint so far is scroll perf. They seemed to go the custom route which is a VERY difficult route to go down. It’s a shame they couldn’t use native scrolling :frowning:

Agreed, probably the biggest issue of note so far.

Yeah, at this point, the scrolling behavior in atom is too broken to use as my default text editor. It might be okay if it didn’t lag as much, or if it wasn’t so choppy, or if the framerate didn’t plummet, but combined, it just feels unusable.

Actually I tried to scroll on 24" FullHD display and on 15" macbook pro retina display. On FullHD it looks okay, but on retina it feels very laggy.


I too have noticed this. I had to pull up Sublime and Atom side by side to make sure I wasn’t crazy. I’m on a 15" retina MBP and while scrolling in Sublime I can still read everything which makes jumping around a long file easy. In Atom something weird is happening that makes it hard to read while scrolling. Going to try and power through for a bit, but have a feeling this issue will send me back to Sublime before long.

1 Like

Anyone w/ the Atom team look into scrolling using translate3d to hook into the GPU? Or -webkit-overflow-scrolling?

translate3d throws everything into memory, and if this + your app uses too much memory. crash. Not sure how they are managing memory elsewhere but turning this on and off also has a cost to it if you were thinking about doing it while scrolling think again. It’s a bugger to get right, and a beast if you use it everywhere like a bandaid. Not saying it’s not the right solution, just a can of worms.

as for -webkit-overflow-scrolling +1 on this. Though I bet they have there reasons for doing custom scrolling. Most likely for memory management.

@JAStanton You’re right about translate3d. Writing a good implementation that can fully replicate scrolling is a difficult task (I did much of it for an app at our company). We never actually had any issues creating an enormous element (hundreds of thousands of px) that sits a layer, as long as we dynamically loaded, staged, unstaged, and eventually removed data dynamically… That is, until iOS.

iOS can’t deal w/ large layers at all, and crashes. So we had to change the implementation from using a huge canvas (not <canvas>) to using a huge “virtual canvas”. Thankfully this didn’t require much refactoring b/c we wrote in AngularJS which meant all the pieces were modular and only a few concepts needed to change.

Nevertheless, this was just two dudes for a short duration trying to create a specific implementation. I would really love to see a fully generic implementation, if anything just as a proof of concept.

There are a number of other interesting concepts (like using canvas or WebGL), which I haven’t investigated. I think this is sort of a holy grail issue in web right. The idea of huge, highly performant scroll areas. Especially ones that can dynamically load data and don’t consume crazy memory.

+1, I’m personally okay with the implementation, but the speed is just too quick. Would love a way to reduce that a bit!

Sideways scrolling is also very jerky and not smooth at all for me

1 Like

+1 , especially when using a scroll wheel.
It’s bearable with a touchpad.

OSX Maverick.

Much better since the last update (0.75). Still a little laggy on a retina display, but it’s much better now.

If scrolling isn’t adjustable yet, maybe we could at least have a scroll bar? That would let me control navigation of the document much better than the crazy scrolling that is currently in place.

Not an issue anymore for me, neither on the rMBP nor an ordinary screen. (0.76)

Much better indeed (0.78) rMBP! Not as smooth as ST for multidirectional scrolling up/right/left/down but with Soft Wrap it’s all good!