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

AtlasEngine: Remove experimental tag and add tracing #13939

Merged
2 commits merged into from
Sep 8, 2022

Conversation

lhecker
Copy link
Member

@lhecker lhecker commented Sep 7, 2022

With AtlasEngine being enabled by default in 1.16 Preview it would look weird
if the useAtlasEngine option would still be called "experimental".
Additionally we're interested in how many users opt out of useAtlasEngine,
indicating major issues that would require us to disable it by default again.

Related to #13936

Validation Steps Performed

  • Toggling useAtlasEngine works as expected ✅
  • Observe new event with TVPP ✅

@lhecker lhecker added Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal. Area-AtlasEngine labels Sep 7, 2022
@lhecker lhecker added this to the Terminal v1.16 milestone Sep 7, 2022
@lhecker lhecker changed the title AtlasEngine: Remove experimental from useAtlasEngine AtlasEngine: Remove experimental tag and add tracing Sep 7, 2022
@lhecker lhecker force-pushed the dev/lhecker/atlas-engine-settings branch 2 times, most recently from 51d6a44 to f8a5b9c Compare September 7, 2022 14:57
const auto& globals = settings->_globals;
TraceLoggingWrite(
g_hSettingsModelProvider,
"AtlasEngine_Enabled",
Copy link
Member

Choose a reason for hiding this comment

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

This is sorta what we were talking about. This is a usage event (user initiated) emitted for something Terminal did (load its settings). Hmm.

src/cascadia/TerminalSettingsModel/MTSMSettings.h Outdated Show resolved Hide resolved
TraceLoggingBool(globals->HasUseAtlasEngine(), "UseAtlasEngineOverridden", "true if useAtlasEngine is set"),
TraceLoggingBool(globals->UseAtlasEngine(), "UseAtlasEngine", "true if AtlasEngine is enabled"),
TraceLoggingKeyword(MICROSOFT_KEYWORD_MEASURES),
TelemetryPrivacyDataTag(PDT_ProductAndServiceUsage));
Copy link
Member

Choose a reason for hiding this comment

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

In team sync you mentioned a bunch of performance data we wanted to get insights into as well. Atlas resizing, etc.
Did you want to include those in this PR as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd have to figure out how to implement them first and I felt like getting this crucial change in ASAP is much more important than that.

Copy link
Member

Choose a reason for hiding this comment

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

I agree with Leonard on this one. Let's start with simple

@lhecker lhecker force-pushed the dev/lhecker/atlas-engine-settings branch from 9a9b411 to 8f4997b Compare September 7, 2022 16:07
Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

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

I'm cool with this, presuming that atlas is a "compatibility" option

@DHowett
Copy link
Member

DHowett commented Sep 7, 2022

I'm okay with the setting moving in the UI to Rendering where it belongs. I do think its logical place makes no sense today. However, its physical place can remain in profiles.defaults.useAtlasEngine. What do you think?

@DHowett
Copy link
Member

DHowett commented Sep 7, 2022

The thing about having a different logical place is that we could have multiple logical places for it. the Rendering page can set the defaults one, but what if you have a profile that overrides it? I don't know.

@lhecker
Copy link
Member Author

lhecker commented Sep 7, 2022

The latest commits removes the "compatibility" prefix and allows the setting to be changed in both places (rendering and advanced default profile settings).

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

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

thanks so much

"AtlasEngine_Usage",
TraceLoggingDescription("Event emitted upon settings load, containing the number of profiles opted-in/out of useAtlasEngine"),
TraceLoggingUIntPtr(enabled[0], "UseAtlasEngineDisabled", "Number of profiles for which AtlasEngine is disabled"),
TraceLoggingUIntPtr(enabled[1], "UseAtlasEngineEnabled", "Number of profiles for which AtlasEngine is enabled"),
Copy link
Member

Choose a reason for hiding this comment

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

Do we maybe want to break this down further?

  • Users that don't have the setting at all (!HasUseAtlasEngineDisabled())
  • Users that explicitly opted in
  • Users that explicitly opted out

and maybe a total number of profiles too? Trying to figure out how many folks actually just set this in profiles.defaults might complicate this...

Copy link
Member Author

Choose a reason for hiding this comment

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

We can infer all the first 3 points from the version number alone...
But I think I just realized that might not be added by default to the event data, right? In that case you're right, I'll have to add something like that.

Since the number of profiles is UseAtlasEngineDisabled + UseAtlasEngineEnabled I think we can infer that if needed for sure.

Copy link
Member

Choose a reason for hiding this comment

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

Ah right, we can infer that the user opted out if Disabled > 0. The version is part of the data we automatically get.

Copy link
Member

Choose a reason for hiding this comment

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

Oh so I guess (Num Preview users)-(preview users with it disabled)=(preview users with it enabled, either by default or explicitly). Okay, that makes sense.

@zadjii-msft zadjii-msft added the AutoMerge Marked for automatic merge by the bot when requirements are met label Sep 8, 2022
@ghost
Copy link

ghost commented Sep 8, 2022

Hello @zadjii-msft!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 6816620 into main Sep 8, 2022
@ghost ghost deleted the dev/lhecker/atlas-engine-settings branch September 8, 2022 19:22
@ghost
Copy link

ghost commented Sep 13, 2022

🎉Windows Terminal Preview v1.16.252 has been released which incorporates this pull request.:tada:

Handy links:

DHowett pushed a commit that referenced this pull request Sep 21, 2022
With AtlasEngine being enabled by default in 1.16 Preview it would look weird
if the `useAtlasEngine` option would still be called "experimental".
Additionally we're interested in how many users opt out of useAtlasEngine,
indicating major issues that would require us to disable it by default again.

Related to #13936

* Toggling `useAtlasEngine` works as expected ✅
* Observe new event with TVPP ✅

(cherry picked from commit 6816620)
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-AtlasEngine Area-Settings Issues related to settings and customizability, for console or terminal AutoMerge Marked for automatic merge by the bot when requirements are met Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants