We now properly set the default JSON values for everything except Display Profiles, which should avoid crashes to desktop if we miss setting a value from it's default in the future. This should help with application robustness.
Just noticed that the Settings, Display Profiles and Game Shortcuts all had different json.net settings for reading and writing across all the modules. Have now standardised across them to make them act the same way.
WinLibrary currently waits 5 seconds if it can't read the taskbar registry, and then it tries again. This is because based on my testing, if a screen layout changes, windows takes up to 20 seconds to update registry to record this fact. We have to wait until windows has finished 4 times before we are sure to have passed the 20 second window.
This is likely the delay you have mentioned. I *think* that I can slightly speed this up. We only MUST to do this delay when we are recording the config (i.e. creating a new display profile), and other times it's kind of a nice to have. So I've attempted to speed this up using a 'fastScan' option for the WinLibrary GetActiveConfig function. This will enable it to only query once for the general scans of the active config, and if there is a problem getting the data it will just accept that fact and will still return quickly. But it will still take up to 20 seconds when creating a new display profile as it is REALLY important we get that data correctly.
Fixes#129
The NVAPI and Windows APIs were checked multiple times in a row due to a logic error. THis has been partially corrected, but needs a lot of work to straighten it out.
There is a possibility that there are two displays with the same UID. This happens with software created displays such as SpaceDesk and Superdisplay. This means that we need to try and figure out which screen is the right screen, and then when we know which screen we were really wanting to
DM will now warn users they will need to recreate their Display Profiles again. I really hope this is the last time I have to do this to my lovely users.
This was a major error that somehow slipped through previous work. WinLibrary was only partially patching the Windows Display Config when it was being loaded, and that resulted in some parts of the Windows Display Config not working after a windows reboot. This should now be fixed!
Fixes#103
IMPORTANT: This patching means that DisplayMagician is able to use your existing Display Profiles, but there is a catch! DisplayMagician won't be able to detect that your old profiles are currently in use... in other words DisplayMagician will constantly think that you have a new Display Profile until you save a copy of the DisplayProfile again.
This occurs because DisplayMagician now gets and compares the NVIDIA 3D Settings and there is no way for us to figure out what previous 3D settings were in use when you set up previous display profiles. For that reason we'll just need you to save new Display Profiles.
There was a flaw in the way that ProgramSettings was being used that meant there was a lot of reloading and saving going on which was unnecessary. Additionally there were some errors in the way that the Settings file was upgraded which mean that the old settings were keeping on getting overwritten. Fixes#104.
This DRS Support is just reserving a space for the future addition of DRS Settings pulled from the driver. This will allow the recording of settings listed in the 3D Settings within the NVIDIA Control panel.
This is a subtle error, caused by either the NVIDIA driver being slow, or windows being slow in updating the location of the windows taskbar edge. This was causing an error in the GetNVIDIASCreenPositions function. Have added a 0.5 second delay to allow windows to update iit's display layout before we try to read it which should help, and also if we can't find the taskbar location in the settings, we just assume it is at the bottom. This should avoid exception.
Partially through a different refactor to completely change how the taskbar settigns are stored, and the logic behind the application. Should make the taskbar more robust to apply.
Added some checks to temporarily pause any 'getconfig' type activities while we're changing the displayconfig. This should result in less config corruption, and fewer errors when there are timing edge cases.
This change makes the ProfileRepository handle loading json config files from later versions of DM without causing an exception. This will mean that you can install later model config files and still have them work ok.
Found that I was combining Threads and Tasks together...never a good idea. Have moved fully over to a Task based model. Now still having issues with parallelism.
Found some calls that were bypassing the video library state buffering I'd put in place earlier. This should generally make DisplayMagician faster and minimise the number of log entries written to DisplayMagician.log.
As I'd changed the profile config to buffer it within the libraries themselves, ApplyProfile wasn't telling the libraries to update their config. Therefore they thought they were still on the original display config, and that meant that ApplyProfile didn't revert the profile after the application had closed. This is now fixed.
Changed Profiles to use new methods for profiles detection provided by the new video card library updates for NVIDIALibrary, AMDLibrary and WinLibrary. This should make DisplayMagician faster as there is less repetition.
There have been such large changes with v2.1.0 that I've had to move to a new file display profile format again :(. I'm really hopeful this will be the last time, as it seems to cope with all the different display layouts, colour settings, hdr etc.
This will ensure that existing display profiles will at least load. Anyone with refresh settings changes or BPC or other device context settings will need to recreate their display profiles.
Now ProfileItem loads properly from JSON file, which means that the profile matching works, so DisplayMagician now matches the profile if it's current.
There was a problem with the unused display config containing null values on save, which meant that the JSON would be invalid when loaded in the next time. The fix was to ensure that both NVIDIA and AMD both were filled with a default config when a new profiles was created. This means that the real config would overwrite whichever config was needed, and the JSON file would work as all objects were populated correctly!
Mostly works now! Only bit still needing work is the Avtive profile detection to detect the non-surround profile when we return from surround. I think it's to do with the windows display number changing :(. I need to check that.
The derived ProfilteItem classes were an unnecessary distraction and wasted time I could be spending on other things. This set of changes are the first part of removing those derived classes and moving to a single ProfilItem class again, but with different configuration slots within it. Makes equality comparison SO MUCH EASIER!
I am a lot closer at the moment, but there is some bit of logic matching that is escaping me. I think I'm just too tired at the moment, and I need a sleep. I bet this will seem simple in the morning.
Used new derived class equality class from https://codinghelmet.com/articles/equals-override which helped me understand the logic for deriving equality between base classes and derived classes. It has now exposed another error in the way FORCED_VIDEO_MODE is being applied and that is now something else I need to fix!
This feature will allow users to bypass the automatic driver detection functionality so that they can at least force the use of the built-in Windows driver if NVIDIA or AMD ever have an issue with their drivers.
