3

I've been facing this issue since El Capitan. Basically, when I resize a window manually, it lags or whatever you want to call it. Here's a video in real time showing this problem.

A gif slowed down 50% can show the mouse pointer leading the entire window redraw as it calculates the layout and then resizes the window with live layout changes.

enter image description here

Notice how the mouse pointer leads and the window lags when you resize the window fast.

My specs:

Processor: 2.5 GHz Intel Core i5
Memory: 16 GB 1600 MHz
Graphics: Intel HD Graphics 4000 - 1536 MB
Disk: 250GB SSD

CPU is not constrained when the lag is present:

enter image description here

Although this doesn't occur on Windows 10 (Same specs), it is still really annoying to deal with, and I'd really like to know if there's anything I could do or change to get rid of this issue...

The question: Is there a way to remove the lag when resizing a window quickly?

UPDATE 2022

Well apparently with the introduction of the M1 chip and macOS Monterey, this is no longer an issue at all. These tasks, at least in macOS, are heavy GPU dependent. Upgrading your hardware should take care of any UI issues.

The following video demonstrates how the UI is more fluid:

https://i.imgur.com/o9Vw2Cn.mp4

Greetings to @bmike

Improve this question
3
  • If you open activity monitor, is there any CPU usage where idle is less than 50% or memory pressure (yellow or green)? Either could easily explain the slow response and the details would get you to a cause of the issue.
    – bmike ♦
    Commented Oct 28, 2017 at 2:54
  • Hello @bmike. Thanks for your comment. I can say that my "Idle CPU%" average is always between 80% and 95%. Even doing heavy work with NodeJS. Here is a screenshot of my CPU usage, keep in mind that I'm working on a project right now and using some NodeJS test tools with it. imgur.com/bwXf7iv
    – Victor Warren
    Commented Oct 28, 2017 at 3:12
  • So I don't think CPU usage is the problem here.
    – Victor Warren
    Commented Oct 28, 2017 at 3:23

1 Answer 1

Reset to default
1

That response looks entirely proper and the only thing I could see would be to have chrome somehow do less calculation of the content inside the frame and just resize the window and redraw / re-layout the text and content at a lower rate.

This seems like an intentional tradeoff - you can see the content is responding almost as fast as the mouse pointer. I'm not up on css / html enough to know if there's a hint you could embed to tell the web layout to not worry about layout changes so much and instead wait for you to pick a window size and then refresh.

My guess is the software isn't optimized for your use case at all. If chrome and safari and Firefox all work the same, you might simply see a decision to use CPU and cap frame rates due to energy consumption considerations and not for inherent limitations in the hardware. It could also be that all the responsiveness and resources are committed to making the content move inside the window so you know you are dragging and less about trying to track a window size change.

Dissecting this would make for an interesting research project or possibly a thesis for someone on software design tradeoffs and implementations. Which is a long way of saying, I don't think there's an easy solution for you to make a meaningful change other than use another browser or OS.

Improve this answer
2
  • Hello, and thanks again for your comment. The content responds as fast as I change the window's size, just as I'd spect from something that is "responsive". I've been testing this on Windows 10 as well and, not only the window's content but the window itself responds faster and smoothly. I guess that's how it works on MacOS.
    – Victor Warren
    Commented Oct 28, 2017 at 14:56
  • Yes @VictorWarren I don't doubt you at all. I believe the animation curves are different on MacOS than they are on Windows. If one does more calculations to ease in the start and end of the animations to make them more natural, the other could simply be more jerky and responsive. (with jerk being the rate of change of acceleration over time as opposed to janky which would be an opinion and not a measurable characteristic of an animation method). The animation rate could also be intentionally nerfed so that chrome uses less power on Mac OS - you'd need that code to know either way.
    – bmike ♦
    Commented Oct 28, 2017 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .