Skip to content

Cursor drift when ofToggleFullscreen(); and ofHideCursor(); are called on Linux #6268

@DanBennettDev

Description

@DanBennettDev

This issue occurs in ofv0.10.1 Linux64 gcc6release

When ofToggleFullscreen() and ofHideCursor() are both on, mouse position behaviour, in calls to e.g. ofGetMouseX(), ofGetMouseY(), is incorrect.

Specifically, in the Y axis (and maybe X also - not confirmed), forward movement seems to be scaled slightly higher than backward movement - e.g. if I move the mouse 1cm up and then 1cm down, there will be a very small net movement up. This is not noticable in one movement, but over a period of use this causes the cursor to drift upwards. This is not a result of mousing style - several users have replicated it, and I have replicated it by moving the mouse in different ways.

This seems to be due to the behaviour of glfwSetInputMode(windowP,GLFW_CURSOR,GLFW_CURSOR_DISABLED);, called in ofAppGLFWWindow.cpp

minimal example:
In app.h

int counter{0};

In app.c

void ofApp::setup(){
    // Open Mouse
    ofSetFrameRate(50);
    ofToggleFullscreen();
}

//--------------------------------------------------------------
void ofApp::update(){
    if(counter++ % 1000 ==1){
        ofHideCursor();
    } else if (counter % 1000 ==0) {
        ofShowCursor();
    }
}

//--------------------------------------------------------------
void ofApp::draw(){
    ofSetColor(0,0,0);
    ofFill();
    ofSetColor(1,1,1);
    ofDrawCircle({ofGetMouseX(), ofGetMouseY()}, 5.f);
}

With this code, if you move your mouse up and down on the spot repeatedly, never moving beyond 2cm up or down from a reference point. The cursor will rise up the screen, until every 1000th frame, when ofShowCursor() is called - at that point the cursor position resets to match the OS cursor position.

A temporary workaround for some purposes is not to call ofToggleFullScreen(), but to use a launcher script to move to fullscreen, as in this post. This effectively fullscreens and prevents the OS cursor from ever showing, and does not call glfwSetInputMode(windowP,GLFW_CURSOR,GLFW_CURSOR_DISABLED) so the drift does not happen. This would not be a workaround for e.g. 3d cam control style applications.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions