[FZ Editor] load time performance #186
Labels
Area-Quality
Stability, Performance, Etc.
FancyZones-Editor
Issue revolving the FancyZone Editor
Resolution-Already Fixed/Doesn't Apply
A change in the product has made the issue obsolete.
Comments
|
@enricogior do we have metrics to prove #778 did improve speed? |
|
The improvement has been marginal, @yuyoyuppe recorded the start-up time measuring the speed in frames/s, I don't recall the exact numbers but I think it was around 10% or less. |
|
Do we have telem put into place for measuring the time from when the editor is requested and the UI is rendered? I would like to get data here so we can validate if this is a larger issue. This way we can start figuring out what the baseline is. |
enricogior
changed the title
enricogior
changed the title
|
Feel like this has been better but wonder if this is since i'm on my desktop. |
enricogior
added
the
Resolution-Already Fixed/Doesn't Apply
|
0.31.2 and 0.33 seems decently fast, let's close this for now. |
stefansjfw
pushed a commit
that referenced
this issue
Dec 18, 2024
A lot of this is just samples work, so skip on down to `src/modules/cmdpal/Microsoft.CmdPal.UI.ViewModels/ActionBarViewModel.cs`. * Updates the Action Bar with the title of the currently active page when we navigate to it * listens for PropChanged events from `ICommandItem`s in lists and on `IPage`'s (to display a loading bar) * Also didn't put this on the ShellPage quite yet, because the diff was already massive, and there's complicated "are _we_ loading the page? did the `IPage` say it was loading?" plumbing that needs to be done. * adds rudimentary support for showing an exception, if there's an error we catch * I didn't add log this everywhere yet though, since we're not 100% confident on the messaging infrastructure here * I decided against putting this on the shell page, because I want users to be able to _go back_ from a page with an exception, and that didn't seem trivial if it was on the shellpage itself * Then updates a bunch of extensions to better utilize the loading state. * Then discovers a really weird bug with event callbacks in WinRT, so I decided to wrap those in try/catches to have extensions explode less often. (#181) * Then also adds a bunch of "evil" samples, to make a unified place of "things to try and break us" ref #73 --------- Co-authored-by: Mike Griese <zadjii@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there anything we could do to get it up and running faster?
The text was updated successfully, but these errors were encountered: