Scrolling performance noticeably worse on retina Mac

[core-ai-bot]

Issue by njx
Thursday Jul 25, 2013 at 21:49 GMT
Originally opened as adobe/brackets#4578

---

This is in current master (with CEF 3.1547.1337)

1. Open Activity Monitor
2. Launch Brackets pointing to the brackets repo
3. Open brackets.js
4. Wait for the process to go down to <1% CPU usage
5. Using the touchpad, throw scroll up and down
6. Compare with the same steps in Sprint 27

Result: In the latest version, scrolling is noticeably worse than in Sprint 27 even on a short file--it's very jerky. If you look at Activity Monitor, you'll see that with the current CEF, there are two Brackets Helper processes, and while scrolling, one of them averages 90-100% CPU usage and the other averages about 20%. In Sprint 27, there was only one Brackets Helper process, and during the same kind of scrolling it averaged about 50% CPU usage.

[core-ai-bot]

Comment by njx
Thursday Jul 25, 2013 at 21:55 GMT

---

FWIW, while I was reproducing this, there was a separate Chrome process (from my browser, unrelated to Brackets) taking up ~50% CPU. Without it, the difference in lag was less noticeable, but the CPU usage difference was still there. So I think there's a real issue here, but it will mostly be visible if something else is also using significant CPU resources.

[core-ai-bot]

Comment by peterflynn
Thursday Jul 25, 2013 at 22:22 GMT

---

Rendering performance has dropped dramatically on very old hardware btw -- I have a first-gen Mactel (Core 1 Duo with 10.6), and many operations are almost unbearably laggy with the new shell. It's very old hardware (2007??), so I don't think we should be worried per se -- but it's another indicator how much the render pipeline has changed in Chromium now.

[core-ai-bot]

Comment by jasonsanjose
Saturday Jul 27, 2013 at 00:01 GMT

---

I'm seeing a similar scrolling slowdown compared to Sprint 27, but I'm using today's build cef-3.1453.1279-v8-crash-redux8525. Since both versions are using the same build of CEF 3.1453.1279, I'm starting to think something else has changed.

Sprint 27: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Brackets/0.27.0 Safari/537.36"
Sprint 28: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Brackets/0.28.0 Safari/537.36

[core-ai-bot]

Comment by jasonsanjose
Monday Aug 05, 2013 at 18:19 GMT

---

Reviewed. Assigned@njx medium priority.

[core-ai-bot]

Comment by Globegitter
Tuesday Feb 25, 2014 at 16:38 GMT

---

Not sure if that is entirely related to the retina macbook, but sometimes scrolling can be a bit laggy for me and in a bigger sized project the Cmd + Shift + O command is really slow. Even after the new caching in Sprint 36 should have already kicked in.
That is really one of my only major issues so far, that performance doesn't seem to be comparable yet to Sublime Text.

[core-ai-bot]

Comment by tkislan
Wednesday Apr 30, 2014 at 21:36 GMT

---

sprint 38 experimental build 0.38.0-12606 (release 4df8afdad)
I can confirm that scrolling through file that has barely 500 lines, can cause CPU usage to go to 100% (one full core), this is just unacceptable
This makes this application unusable on laptop, as it devours the whole battery

[core-ai-bot]

Comment by njx
Wednesday Apr 30, 2014 at 21:53 GMT

---

@tkislan I can reproduce that if I continuously scroll for a long period. However, doing the same test in Sublime Text shows over 50% CPU usage. So we're definitely worse by a factor of 2, but not an order of magnitude. That suggests to me that we have a decent chance of improving the CPU usage to more acceptable levels with the same optimizations that would make scrolling smoother, if we can find any.

[core-ai-bot]

Comment by tkislan
Wednesday Apr 30, 2014 at 21:55 GMT

---

Was just trying the exact same thing, on the exact same project
I couldn't get Sublime on more than 30% CPU
Light Table is around 50%
But Brackets is taking alot more

[core-ai-bot]

Comment by njx
Wednesday Apr 30, 2014 at 21:58 GMT

---

Yeah, Sublime is definitely more efficient generally - I can get it to 50% by throw scrolling a lot, but normally it hovers around 20-30%, whereas Brackets hovers around 60-70% and gets up to 100% if I keep going. Still, it doesn't seem so far out of whack as to be unfixable.

[core-ai-bot]

Comment by njx
Wednesday Apr 30, 2014 at 21:59 GMT

---

(Having done a little profiling on the CodeMirror side, it seems like CM might be doing more style invalidation/repaints than necessary in some cases, so I think there might be some moderately low-hanging fruit there.)

[core-ai-bot]

Comment by tkislan
Wednesday Apr 30, 2014 at 22:04 GMT

---

But I still prefer Brackets, as it handles the code intel automatically, compared to Sublime, where I cant get it to do it at all

So if you need any hand with debuging, Im eager to help

[core-ai-bot]

Comment by njx
Wednesday Apr 30, 2014 at 22:37 GMT

---

Thanks. We do have scrolling performance on our near-term backlog (along with other perf issues), so hopefully we'll be able to make some progress in improving this within the next few releases.

[core-ai-bot]

Comment by njx
Saturday Jul 12, 2014 at 03:28 GMT

---

Leaving unassigned since this is on the backlog already.