Input and Windowing via GLFW

[daerogami]

This PR at the time of creation represents the initial prototype of using GLFW inplace of the legacy Platform code.
This decision is not final and purely serves as a springboard from which to spur discussions around viable and pragmatic improvements.
Lets have all general discussion occur in #866 whereas specific discussion around the implementation presented in this PR happen here.

Closes #824

[varon]

Nice work, @daerogami. Looks like it's coming along decently. There's a lot of code added here, so consider this a super early non-judgemental review.

• I'd suggest doing a separate PR for OpenToolkit.Input first if you need it, things like Key, Mouse, etc should all live in that project. Handling them one at a time makes reviewing much easier.

We could also trim this down by swapping out the license headers to the new one:

//
// <filename>
//
// Copyright (C) <year of creation> OpenTK
//
// This software may be modified and distributed under the terms
// of the MIT license. See the LICENSE file for details.
//

via @Nihlus in #829

[varon]

also, watch out for potential duplicates via #861!

[daerogami]

also, watch out for potential duplicates via #861!

Will probably make sense for me to rebase off of that branch since maintaining the current GameWindow API heavily depends on existing Input. Not sure how this will tie into GLFW since it handles input as well, haven't researched that far ahead.

[Perksey]

Can't help but notice this doesn't implement the whole API. For it to be viable to replace the platforms of OpenTK, we'll need the whole API. See http://www.glfw.org/docs/latest/

[varon]

@DylanFPS - I'm not sure sure we want to expose the API at all. The purpose of this prototype is to determine if we can replace the current GameWindow (which doesn't expose native functionality) functionality with GLFW.

[Perksey]

Yeah but afaik the contents of this PR isn't enough to match the current GameWindow API (mainly the functions required for input)

[Perksey]

Also @varon why wouldn't we want to expose the entire API? Overachievers/people who want to follow C tutorials exactly might want to veer away from our GameWindow API. While we can all call them nuts for doing so, I wouldn't want to block it completely. Moreover, by taking just what we need, we're restricting any posibility that there might be something that the user wants from GLFW or GameWindow that they can't have because we simply haven't implemented it. I think we should have this module complete to the best of our abilities.

[Nihlus]

The question we musk ask ourselves is the intent behind the action. Are we implementing bindings to GLFW for use by us, or are we providing them as a service to the end user?

I'm inclined to choose the former, at least for now, since it reduces the amount of work needed in the present and allows us to move faster with the new GameWindow implementation. Further, if we intend on providing them to the end user, the focus of the PR should be the bindings themselves, and the GameWindow's use of them should be at best a secondary objective.

Both views have merit, of course, but given the current situation I believe that our energy is best spent on a smaller, internal binding for our own use at this point. Once we know we can use it, and once we know what our infrastructure will look like, we can expand the system to a full-scale user-consumable one.

[Perksey]

With the release workload in mind, I think we should only include the bindings required for GameWindow - our main objective at this point should be preserving the API. However, I strongly agree that we should revisit implementing the complete API for a later module release. (I think we should create an issue for this after merge)

[daerogami]

The intent is to carry over INativeWIndow and IGameWindow and implement as much of it as possible using GLFW bindings. I think we are all on the same page on that part. We still need to figure out what this means for inputs, I don't know if we can ignore GLFW's input device features and roll with the legacy stuff because it pulls from platforms which this PR is trying to help us remove.

[Perksey]

GLFW should be able to do most of the job, including input so we do need those APIs. Hopefully by the time GameWindow is fully rebuilt there’s no need for platforms.

[varon]

How are we looking here? Ready for that review?

[devvoid]

Yes, but I won't be able to act on that review for another week or two, it's almost finals week.

[devvoid]

I'm considering whether or not we should just get rid of the windowing tests - so long as ADL functions and GLFW doesn't have any massive API-breaking updates, I don't see this as being something that would break in an OpenTK update. Plus, everything we've tried to get them to work on the CI just doesn't work.

[jvbsl]

As far as I can tell as long as my PR for ADL gets merged(still need to get the tests to work there as well :D Tests seem to be my enemies in OpenTK) the tests I have in a branch of mine should work on Linux and Windows as well. But I need to find enough time to do it.

[varon]

Windowing is a nightmare to test, especially on CI. I strongly encourage skipping them and spending the time on more important areas instead.

As long as you run any app at all, it's always going to be immediately obvious that windowing is broken.

[varon]

Going to start review on #871 first, as I'd like to see travis CI working for this if we can!

[devvoid]

Sounds good, I still have another three days of finals before I'm free anyways

[devvoid]

I got Travis to work again! There's still the multithreading issue (see Discord for more info), but otherwise, this should be 100% ready to go.

[jvbsl]

Wow can't believe that this is the fix. I explicitly added this line, because there were dotnet installation problems which were fixed by that(and it did work completely) :D

[devvoid]

Ah, Travis, we love you, but you can be a royal pain...

[devvoid]

Now that the threading thing is solved, unless there's anything else, this PR is now feature-complete.

That being said, I'd prefer to wait until after #908 is merged. There's a few places where float vectors are used, but integer vectors would be much cleaner.

However, this is ready for a review whenever a maintainer is free to do it.

[varon]

Let's aim to get those int vectors merged in if we can first!

[TheRealNOIG]

Does this GLFW GameWindow replace the original platform or is this a option to the original platform?

[varon]

Completely replaces the native and SDL backends.

We're now only maintaining one, "high level" backend compared to four, which is a huge boost in our ability to ensure feature parity and reduce bugs across platforms.