I've noticed that the standard cursor behavior in my April Update-consuming Silk application with GLFW backend has changed.
When updating the current standard cursor, weirdly the shown cursor seems to be lagging and show the previous value.
I've had a look into the current implementation and I noticed, that the April update introduced a change to the StandardCursor logic that looks like it may be the culprit:
Since UpdateCursor() calls into GetStandardCursor() which in turn depends on the _standardCursor field, moving the _standardCursor assignment after UpdateCursor() would change the outcome.
When I revert the change with some private reflection, my application again sets standard cursors as expected:
public static void SetStandardCursor(this IMouse mouse, StandardCursor stdCursor)
{
var cursor = mouse.Cursor;
if (cursor.StandardCursor == stdCursor) { return; }
var cursorType = cursor.GetType();
var stdCursorFld = cursorType.GetField("_standardCursor", Instance | NonPublic)!;
var updateStdCursorMethod = cursorType.GetMethod("UpdateStandardCursor", Instance | NonPublic)!;
stdCursorFld.SetValue(cursor, stdCursor);
updateStdCursorMethod.Invoke(cursor, null);
}
Hi,
I've noticed that the standard cursor behavior in my April Update-consuming Silk application with GLFW backend has changed. When updating the current standard cursor, weirdly the shown cursor seems to be lagging and show the previous value.
I've had a look into the current implementation and I noticed, that the April update introduced a change to the StandardCursor logic that looks like it may be the culprit:
Since
UpdateCursor()
calls intoGetStandardCursor()
which in turn depends on the_standardCursor
field, moving the_standardCursor
assignment afterUpdateCursor()
would change the outcome.When I revert the change with some private reflection, my application again sets standard cursors as expected: