Performance issue when using CSS animations

[dsl101]

Describe the bug

I'm using ACE as part of a larger app based on the Quasar / Vue frameworks. The framework provides UI components such as popup dialogs which use CSS transforms. Two of these in particular (scale & rotate) cause significant stalling on Chrome on MacOS. Only that browser / OS combination appear to be affected, but it is pretty reproducible on that combination.

In addition, this symptom is only triggered if the editor has content on first load—setting the value of the editor after the animation has finished causes no performance issues.

Expected Behavior

The editor would open normally, regardless of the CSS transform used.

Current Behavior

Certain types of transform (scale & rotate) cause Chrome on MacOS to stall.

Reproduction Steps

This codepen illustrates the problem on Chrome on MacOS:

• The first button triggers the dialog using the 'scale' transition with initial content set, and stalls for several seconds.
• The second triggers the same dialog using the 'fade' transition, and works as expected.
• The third button triggers the dialog using the 'scale' transition, but delays setting the content by 500ms, enough for the CSS animation to complete, and works as expected.

Possible Solution

No response

Additional Information/Context

During the stall, Activity Monitor shows 100% CPU in the Google Chrome Helper (Renderer) process, and Chrome performance tools show this is for the Composite Layers activity.

This problem only shows up if the editor session contains text when the CSS animation is in progress. Loading the editor component after the animation, or setting the content after the animation does not trigger the problem.

This may very well be a Chrome bug, but since it only shows up when using the ACE editor, I thought I would file it here first to see if there is an easy fix, or more information available about what ACE might be doing during that animation.

Ace Version / Browser / OS / Keyboard layout

ACE 1.15.2 / Chrome 110.0.5481.177 / MacOS 12.4, 12.5, 13.2.1

[nightwing]

This appears to be a bug in chrome which is triggered by our use of will-change css property
Adding

.ace_hidpi .ace_text-layer,
.ace_hidpi .ace_gutter-layer,
.ace_hidpi .ace_content,
.ace_hidpi .ace_gutter {
    will-change: initial!important;
}

or even

.ace_hidpi .ace_text-layer {
    will-change: initial!important;
}

seems to fix the issue.

We'll need to investigate if will-change still provides better performance in some situations, and if it is possible to mitigate the issue without removing it.

[dsl101]

Thanks for the quick response. This seems sufficient for our app, even without the !important. We'll use this as a workaround for now.

.ace_hidpi .ace_text-layer {
    will-change: initial;
}

[InspiredGuy]

@dsl101 hey, could you please confirm if that workaround to mitigate Chrome bug was enough to resolve your issue?

[dsl101]

Yes, that CSS I posted is sufficient in our use case.

[InspiredGuy]

Thanks for the confirmation, I will close this issue in this case as resolved. Feel free to reopen if you encounter the same behaviour elsewhere.

[dsl101]

Hmm—I thought this would stay open until it was fixed in ACE (or has that CSS been included now?).

…

On Fri, 17 Mar 2023 at 18:17, Zakhar Kozlov ***@***.***> wrote: Thanks for the confirmation, I will close this issue in this case as resolved. Feel free to reopen if you encounter the same behaviour elsewhere. — Reply to this email directly, view it on GitHub <#5074 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG33PRXKV3ONZRYZWWWHZTW4STDPANCNFSM6AAAAAAVMLWI5M> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[InspiredGuy]

Agree, this could be investigated on the Ace side further, reopening the issue.