Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid animations during startup #15204

Merged
merged 1 commit into from
Apr 20, 2023
Merged

Conversation

lhecker
Copy link
Member

@lhecker lhecker commented Apr 18, 2023

This fixes 3 sources for animations:

  • TabView's EntranceThemeTransition causes tabs to slowly slide in
    from the bottom. Removing the transition requires you to override the
    entire list of transitions obviously, which is a global change. Nice.
    Am I glad I don't need to deal with the complexity of CSS. /s
  • TabBase, SettingsTab and TerminalTab where using a lot of
    coroutines with resume_foreground even though almost none of the
    functions are called from background tabs in the first place. This
    caused us to miss the initial XAML drawing pass, which resulted in
    animations when the tab icons would asynchronously pop into existence.
    It also appears as if resume_foreground, etc. have a very high CPU
    cost attached, which surprises me absolutely not at all given WinRT.

The improvement is difficult to quantify because the run to run
variation is very high. But it seems like this shaves about 10% off
of the ~500ms startup delay on my PC depending on how you measure it.

Part of #5907

PR Checklist

  • It starts when it should ✅
  • It doesn't "exit" when it shouldn't ✅
    (Scrolling, Settings reload, Bell \a, Progress \e]9;4;2;80\e\\)

@lhecker lhecker added Area-Performance Performance-related issue Product-Terminal The new Windows Terminal. Automerge-Not-Compatible labels Apr 18, 2023
@lhecker
Copy link
Member Author

lhecker commented Apr 18, 2023

Before
before

After
after

Side effect: Scrollbars are more responsive now

w7rsxTfcrsAhEKgU.mp4

@DHowett DHowett force-pushed the dev/lhecker/lazy-command-palette branch from d11290c to 83bb7e0 Compare April 19, 2023 18:20
@DHowett DHowett force-pushed the dev/lhecker/startup-animations branch from 649f89b to 082aef0 Compare April 19, 2023 18:20
Base automatically changed from dev/lhecker/lazy-command-palette to main April 19, 2023 19:18
@DHowett DHowett force-pushed the dev/lhecker/startup-animations branch from 082aef0 to bf8d0b5 Compare April 19, 2023 19:32
@@ -961,11 +961,11 @@ namespace winrt::Microsoft::Terminal::Control::implementation

auto bufferHeight = _core.BufferHeight();

ScrollBar().Maximum(bufferHeight - bufferHeight);
ScrollBar().Maximum(0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HAHAHA

ScrollBar().Minimum(0);
ScrollBar().Value(0);
ScrollBar().ViewportSize(bufferHeight);
ScrollBar().LargeChange(std::max(bufferHeight - 1, 0)); // scroll one "screenful" at a time when the scroll bar is clicked
ScrollBar().LargeChange(bufferHeight); // scroll one "screenful" at a time when the scroll bar is clicked
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there must have been a reason it was bufferHeight-1, right?

Copy link
Member Author

@lhecker lhecker Apr 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could be because the original author compared the behavior against less, where PgUp/Down moves by 29 lines in a 30 line viewport. But that's because the 30th line is the ":" command prompt. Setting this to bufferHeight does do what you'd think it does (= page by 30 rows / the viewport height) and is the more correct behavior IMO.

@DHowett DHowett enabled auto-merge (squash) April 19, 2023 22:54
@DHowett DHowett disabled auto-merge April 19, 2023 22:54
@DHowett DHowett enabled auto-merge (squash) April 19, 2023 22:54
@DHowett DHowett merged commit 35b9e75 into main Apr 20, 2023
@DHowett DHowett deleted the dev/lhecker/startup-animations branch April 20, 2023 12:31
DHowett pushed a commit that referenced this pull request Apr 25, 2023
This fixes 3 sources for animations:
* `TabView`'s `EntranceThemeTransition` causes tabs to slowly slide in
  from the bottom. Removing the transition requires you to override the
  entire list of transitions obviously, which is a global change. Nice.
  Am I glad I don't need to deal with the complexity of CSS. /s
* `TabBase`, `SettingsTab` and `TerminalTab` were using a lot of
  coroutines with `resume_foreground` even though almost none of the
  functions are called from background tabs in the first place. This
  caused us to miss the initial XAML drawing pass, which resulted in
  animations when the tab icons would asynchronously pop into existence.
  It also appears as if `resume_foreground`, etc. have a very high CPU
  cost attached, which surprises me absolutely not at all given WinRT.

The improvement is difficult to quantify because the run to run
variation is very high. But it seems like this shaves about 10% off
of the ~500ms startup delay on my PC depending on how you measure it.

Part of #5907

* It starts when it should ✅
* It doesn't "exit" when it shouldn't ✅
  (Scrolling, Settings reload, Bell `\a`, Progress `\e]9;4;2;80\e\\`)

(cherry picked from commit 35b9e75)
Service-Card-Id: 89001994
Service-Version: 1.17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Performance Performance-related issue Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants