New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glfwPollEvents() takes 500ms while keyboard backlight fades in/out on macOS #1283

Open
mackie89 opened this Issue Jun 3, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@mackie89

mackie89 commented Jun 3, 2018

I've noticed that glfwPollEvents() "freezes/locks" up and takes 500ms while keyboard backlight fades in/out on my macOS.. I'm guessing it's spamming the events somehow? anyone else experience this? is it a bug or do I need to tell glfw to ignore it somehow?

@mackie89 mackie89 changed the title from glfwPollEvents() takes 500ms while keyboard backlight fades in/out macOS to glfwPollEvents() takes 500ms while keyboard backlight fades in/out on macOS Jun 3, 2018

@OlivierSohn

This comment has been minimized.

OlivierSohn commented Jun 3, 2018

I've never noticed this behaviour, but adding logs to the function void _glfwPlatformPollEvents(void) in https://github.com/glfw/glfw/blob/master/src/cocoa_window.m#L1564, would help to figure out what is going on : maybe as you said many events are sent at once - or maybe not, and it's another issue?

Then, if many events are sent, maybe we could filter them and use [NSApp sendEvent:event] only for those that are relevant.

@mackie89

This comment has been minimized.

mackie89 commented Jun 5, 2018

So I added some logging to track the number of events each call and also a bunch of timings in the function, it looks like when the backlights fade in/out there are no events being fired but

NSEvent* event = [NSApp nextEventMatchingMask:NSEventMaskAny
untilDate:[NSDate distantPast]
inMode:NSDefaultRunLoopMode
dequeue:YES];

still takes ~500ms to return a nil event, so I guess whatever the internals of that do causes it to get stuck in that situation.. sorry my objective c isn't that great so not sure I can help much more beyond this.

@OlivierSohn

This comment has been minimized.

OlivierSohn commented Jun 5, 2018

Interesting. I'm trying to reproduce it on my side:

#include <stdio.h>
#include <unistd.h>

#include <GLFW/glfw3.h>

void error_callback(int error, const char* description)
{
    fprintf(stderr, "Error (%d) : %s\n", error, description);
}

int main() {

    // disable stdout buffering, to see logs immediately.
    setbuf(stdout, NULL);
    
    if (!glfwInit())
    {
        return 1;
    }
    
    glfwSetErrorCallback(error_callback);
    GLFWwindow* window = glfwCreateWindow(640, 480, "My Title", NULL, NULL);
    if (!window)
    {
        return 2;
    }
    glfwMakeContextCurrent(window);
    
    while(!glfwWindowShouldClose(window)) {
        glfwPollEvents();
        printf(".");
        usleep(10000);
    }

    glfwDestroyWindow(window);
    return 0;
}

// build on OSX :
// g++ main.cpp -std=c++14 -I"/usr/local/Cellar/glfw/3.2.1/include/GLFW/" -lglfw3
// build on linux:
// g++ main.c -std=c++14 -lglfw -lpthread

I ran the program above, on MacBookAir 13 inches, early 2015 / OSX 10.13.4 and saw no visible change in the frequency of dots written in the console when I was either manually changing the keyboard lighting using fn+ f5/f6 or using the system setting "Automatically deactivate keys backlight after (x) seconds of inactivity" to change the keyboard backlighting.

@mackie89 which method do you use to fade the backlight keys?

If you use the same method, could you please run the program I copy pasted and report on the outcome when you change the backlight?

  • if you see the same result as me (i.e no pause), then it means something in your program is different from this sample program and makes this behaviour appear: could you try to incrementally change the sample program to see what feature makes the behaviour change?
  • On the other hand, if you see a pause with the sample program, then it would interesting to know which version of OSX you run on, and on which hardware. (Also, try tu upgrade to OSX 10.13.4 if you can and see if it fixes it?)
@OlivierSohn

This comment has been minimized.

OlivierSohn commented Jun 5, 2018

After some googling, I think I found what the issue is: you are probably affected by this issue that concerns only some hardware:

I have the same thing on my 2017 13" MacBook Pro. I checked multiple MacBooks at work (13" and 15" from 2015 to 2017) and not a single one of them has this issue.

To confirm that your hardware suffers this condition, you can try what rafaelmaza suggests and see if you have the same result. If you do, then it looks like it's an Apple hardware / software bug, glfw has nothing to do with it:

I've just noticed something very weird: this apparently only happens with the application in foreground.

To test this, open a video on YouTube and set the backlight timeout to 5 seconds. Leave the browser in foreground ("focused") with the video playing, wait until the backlight is off and touch the trackpad - the video lags... 😠 Now, pull up another application to the foreground (I tested with the keyboard settings window), obviously making sure it doesn't cover the whole browser window, so you can still see the video running in the background. Do the same process again: wait until the backlight is off and touch the trackpad - BAM, no lagging. :wat:

@mackie89

This comment has been minimized.

mackie89 commented Jun 5, 2018

Yeah looks like it might be the same issue, I'm using a MacBook Pro 15" 2017 on OSX 10.13.4 and was just using the automatic 5 seconds timer, I will try fn+ f5/f6 but my guess is the fact you are using the keyboard to turn it off it might not happen. I will test your code when I get home tonight just to be sure it's not something else in my code. then I'll submit a bug with Apple if it's them :)

@OlivierSohn

This comment has been minimized.

OlivierSohn commented Jun 5, 2018

Maybe you misunderstood : I tested both ways, using the keyboard, and using the settings, both work fine for me with the test program!

If you confirm that you reproduce the issue with my test program, I think it's safe to close this issue, as it's rather an Apple-bug.

@mackie89

This comment has been minimized.

mackie89 commented Jun 6, 2018

Yeah looks like an apple issue, even with your basic program I get a stall with the automated fade in/out. I've submitted a lengthy dev bug with Apple with all the information we have. Thanks for help debugging this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment