The currently used AdamsLair.OpenTK dependency is far behind the latest opentk/opentk version. Consider upgrading.
Analysis
There is a somewhat big risk in updating, as the current state of upstream OpenTK is unclear. While some yet unknown issues may be fixed, others might be introduced.
The current CI build status on the readme page is "unknown" on windows and "failing" on linux / mac, maintainers are wanted. It is unclear to which degree the current upstream repo is in a production-ready state.
If updating, the target should probably be develop, as the current 4.0 branch will introduce more breaking changes and should probably be considered experimental. It also seems to introduce lots of project wide style changes, making it very difficult to see what actually changed in the implementation.
The develop branch seems to contain a big rename / directory change, which could complicate merging into AdamsLair develop.
The develop branch also seems to have switched to a different package management system and no longer builds in VS out of the box.
A very careful way to update would be to gradually copy-paste upstream files to duality-master, reviewing every change and forming new commits. This would allow to only change very specific parts of the currently used OpenTK lib, with full awareness about the kind of changes that were made.
A subset of upstream changes was merged thid way in #683.
Summary
The currently used
AdamsLair.OpenTKdependency is far behind the latest opentk/opentk version. Consider upgrading.Analysis
develop, as the current4.0branch will introduce more breaking changes and should probably be considered experimental. It also seems to introduce lots of project wide style changes, making it very difficult to see what actually changed in the implementation.developbranch seems to contain a big rename / directory change, which could complicate merging into AdamsLairdevelop.developbranch also seems to have switched to a different package management system and no longer builds in VS out of the box.duality-master, reviewing every change and forming new commits. This would allow to only change very specific parts of the currently used OpenTK lib, with full awareness about the kind of changes that were made.