scroll lag after opening and closing calendar (or any other overlay like autocomplete)

[fxck]

See https://youtu.be/1VE5vHXnL84

It feels as if something is not properly cleaned up.

The popover component I'm using is https://github.com/ncstate-sat/popover and is internally using overlay as well.

Also worth noting is that it happens with or without dev tools open and nothing seems out of the ordinary in the performance and rendering tab.

I'll try to make a repro later today.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

6.4.0 material, 6.0.9 angular

[fxck]

https://stackblitz.com/edit/material-scroll-lag-9qzbai?file=app%2Fsimple-example%2Fsimple-example.component.ts

could not replicate it, any ideas? I mean if it was for the sheer amount of components it contains, it wouldn't just start behaving like this after opening component with an overlay, right..

[crisbeto]

Maybe this is happening as a result of a combination of components? It might be easier to see what's going on by doing a recording in the "Performance" tab.

[crisbeto]

One more thing to try: once you've opened it a few times and it starts lagging, can you try finding the cdk-overlay-container in the DOM and adding a display: none to it, and seeing if the lag goes away?

[fxck]

One more thing to try: once you've opened it a few times and it starts lagging, can you try finding the cdk-overlay-container in the DOM and adding a display: none to it, and seeing if the lag goes away?

Can't, it would hide the popover as well.

[crisbeto]

It's a bit more work, but you should be able to hide the cdk-overlay-connected-position-bounding-box for the closed overlays.

[fxck]

Ok, that did fix the lag.

[crisbeto]

Cool, thanks for checking. In that case we should move the detached overlays out of the DOM completely.

[fxck]

I still can't quite understand why is it happening, that cdk-overlay-connected-position-bounding-box seems harmless..

[crisbeto]

It's because, even though they're transparent and unclickable, the elements are still being rendered over the page. Since they're position: fixed, they have to be redrawn while you're scrolling.

[fxck]

Was this really fixed? Experiencing the problem still using 6.4.7..

[fxck]

And it looks like cdk-overlay-container is still in DOM after closing the popover..

[crisbeto]

The cdk-overlay-container is still in the DOM, but it's display: none so it won't have an effect on rendering.

[fxck]

But it does. Or something does. Nothing really changed since it was "fixed". See https://youtu.be/rvzkiTx4_Fk it's smooth the first time I open the popover, after I close it and open it again, it lags a lot..

[crisbeto]

For what it's worth, that fix actually went into 7.0.0-beta.0, but judging by your video you're running Angular 6.1.8.

[fxck]

That's why I asked in the first place, looking the changelog it seemed like the fix was included in 6.4.3 monelite-meeple and I'm running "@angular/material": "6.4.7"..

[crisbeto]

I'm not sure why it ended up in both versions, but an easy way to verify it is to open and close the overlay a couple of times, click around the page somewhere to trigger a round of change detection and see if the cdk-overlay-container is empty.

[fxck]

Also cdk-overlay-container is indeed display: none;.. but it doesn't fix the lag.. funnily enough it did, when I previously added it manually, as mentioned here #12341 (comment)

[crisbeto]

Then it's most likely something different, but it's hard to say by looking at a video.

[fxck]

What can I do (to help you debug it)?

[crisbeto]

Taking a performance recording while scrolling on a list that is laggy could help identify where it's coming from.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}