#19 - WinForm Blackout Screen Timing Customization + #29 - Saving Profile Names from "Edit"

[strazto]

Related issues:

#19 , #29

I've gone ahead and implemented the relevant changes to enable this feature.
Now profile switch timings can be set, and from the "Edit" menu, saving is possible.

Let me know if there's anything that I should change before this PR is ready to merge.

Also, one of us should probably bump the minor version @falahati

[falahati]

Hey,
Thanks for the PR. However, that's just the duration of the splash screen. The real action is what keeps the system busy. Check these lines:

HeliosDisplayManagement/HeliosDisplayManagement.Shared/Profile.cs

Line 268 in 22b2474

Thread.Sleep(2000);

HeliosDisplayManagement/HeliosDisplayManagement.Shared/Profile.cs

Line 303 in 22b2474

Thread.Sleep(18000);

HeliosDisplayManagement/HeliosDisplayManagement.Shared/Profile.cs

Line 313 in 22b2474

Thread.Sleep(10000);

That being said; the process has two profiles at each end, I think we should also respect the already active profile. What if for example, the starting profile is too complicated? Should we average the delay between the old and new profiles?

Meanwhile; we probably can safely modify the code to remove the unnecessary delay. For example:

HeliosDisplayManagement/HeliosDisplayManagement.Shared/Profile.cs

Line 268 in 22b2474

Thread.Sleep(2000);

It can be deleted safely. I just put that 2-sec delay there for the splash screen to show countdown so the user knows something is happening before starting to change display config that might block the user's view.

Or the 18-sec delay for surround settings to apply here:

HeliosDisplayManagement/HeliosDisplayManagement.Shared/Profile.cs

Line 303 in 22b2474

Thread.Sleep(18000);

We can safely remove that when the surround is disabled in both the old profile and the target profile. Or generally whenever the surround settings won't change as the result of profile switch.

The same thing can be done for the 10-sec delay for the general display arrangement configuration here:

HeliosDisplayManagement/HeliosDisplayManagement.Shared/Profile.cs

Line 313 in 22b2474

Thread.Sleep(10000);

We can maybe decide how much difference there is before applying the new config. In some cases like turning a 3 extended profile into a 3 display surround the applied settings after enabling surround are completely right and we might be able to even completely skip this step along with the 10-sec delay. In my tests, however; Windows was lazy to report the changes to the current settings and it made it hard to detect if we also need to reconfigure display arrangments in order to skip this step.

In my opinion; we should first try to fix these issues and optimize the procedure as best as we can and then decide if we should give the end-user the ability to override settings. The real issue is the fact that I hardcoded these numbers and not necessarily the amount of time it takes to switch to and from a profile. I choose 18, 10 and 30 just to be safe; but he process might happen immediately (like when the only difference is the primary display) or takes as long as the NVidia drivers or the Windows feel like.

[falahati]

These are my ideas, for now, I will try to write the implantation when I find some free time. I would appreciate any PR meanwhile.

1. Check if the surround is active in the current profile or the target profile. Skip surround timer and code if this was the case.
2. Make an educated guess of display arrangement configurations after surround activation or deactivation. If no change was found to be necessary, skip the display arrangement configuration timer but check again later to see if it is necessary to run the code anyway and automatically add to the timer (should rarely happen).
3. Choose a time based on the level of display arrangement changes. If for example any new device should be turned on/off or if the changes only affect already active displays. Does the profile contain different resolutions for devices (or refresh rate) that should be applied? Things like display order and primary display config should happen faster than changing resolution.
4. Find a way to detect the end of each operation somehow so we can remove the hardcoded timers.

Edit
This might be useful:
https://stackoverflow.com/questions/33762140/what-is-the-notification-when-the-number-of-monitors-changes/33762334

[strazto]

I now understand what you were talking about WRT the hardcoded timings -
I think maybe our best bet to get started is to implement it by way of a FSM ?
For the time being, the state changes could be hard-coded based on time estimates, but as we start to wrap our heads around it we can fix the state changes to be based on required changes/ notifications about successful changes.

On the UI side, for the splash screen, maybe giving an indicator of the current state / a progress bar could be a nice way to communicate that to users.

I see also why this is something you've deferred for a while - I underestimated its scope but it looks to be a bit of a chore

[falahati]

Closed in favor of #33