OpenTK.Platform.Windows.Functions.GetRawInputData

[Tyrrrz]

The call rate of this function increases proportionally to mouse movement rate, which decreases performance.

[Frassle]

Firstly new issues with OpenTK should be opened on the official github page. Secondly there isn't a lot that we can do here, if you move the mouse a lot then we need to call Windows to get the movement data. In most cases the rate of movement by human users and the subsequent overhead of calling GetRawInputData should be negligible. If you have a real use case and performance problem describe it and we can have a look.

[thefiddler]

It is true that WM_INPUT processing takes more CPU time than WM_MOUSE* messages. Windows tries to consolidate multiple WM_INPUT messages into a single WM_MOUSE* message in order to conserve CPU time. While this is good for general purpose UIs, it is bad for games.

GetRawInputData marshals a struct from unmanaged code to managed, which has relatively high overhead. We might be able to optimize this. However, to do that we'd need a concrete test case that can quantify this performance decrease:

using (var gw = new GameWindow())
{
    gw.UpdateFrame += (sender, e) =>
    {
        var mouse = Mouse.GetState();
    };
    gw.Run(60);
}

How many milliseconds does it take to process Mouse.GetState() here (a) when the mouse does not move and (b) when the mouse is moving continuously?

Edit: this page has been around far longer than opentk/opentk, so I wouldn't call it unofficial. It would be nice if these could somehow be merged. I had no idea how github worked when I branched opentk/opentk, so I botched it completely (the correct approach would have been to promote andykorth/opentk to the "organization" opentk/opentk.) My apologies @andykorth

[Frassle]

We might be able to optimize this.

The only way I can think of doing that is by changing this to a calli instead of pinvoke call?

Edit: this page has been around far longer than opentk/opentk, so I wouldn't call it unofficial. It would be nice if these could somehow be merged. I had no idea how github worked when I branched opentk/opentk, so I botched it completely (the correct approach would have been to promote andykorth/opentk to the "organization" opentk/opentk.) My apologies @andykorth

Semi-official :) It just helps if we can herd everyone to the same place. Also have you tried github support? They should be able to fix it up.

[thefiddler]

The only way I can think of doing that is by changing this to a calli instead of pinvoke call?

If this is indeed a bottleneck, we can work with stackalloc and unsafe pointers instead of marshaling the whole struct. However, I would do this only if there are numbers to prove that this is indeed a bottleneck, otherwise it would be effort spent for no gain.