using QKeyEvents

mzimmers

Update: I submitted a bug report on this; no movement on it yet.

One of my users noticed that the application is now rather CPU-intensive. I verified that it was the key filter by disabling this code in my main widget:

    m_keyPress = new KeyPress(this);
    connect(m_keyPress, &KeyPress::keyEvent, this, &Widget::handleKeyEvent);
    installEventFilter(m_keyPress);

Here's the filter:

bool KeyPress::eventFilter(QObject *obj, QEvent *ev)
{
    Q_UNUSED(obj)

    bool rc = false;
    int key;
    QKeyEvent *qke;
    QEvent::Type type = ev->type();
    if (type == QEvent::ShortcutOverride || type == QEvent::KeyRelease)
    {
        qke = static_cast<QKeyEvent *>(ev);
        key = qke->key();

        // don't bother signaling when the key isn't meaningful to us.
        if (key == 'c' || key == 'C' || key == 'd' || key == 'D')
        {
            emit keyEvent(*ev, key);
        }
        rc = true;
    }
    else
    {
        rc = QObject::eventFilter(obj, ev);
    }
    return rc;
}

I don't see anything really inefficient in my code, but with this enabled, the app uses ~15% of my CPU (on an i3) at idle. Is this to be expected, or am I doing something wrong?

Thanks...

SGaist

What type of widgets are you checking ?
You can add an additional check for the obj parameter class to avoid further checks.

JonB

@SGaist
If @mzimmers says:

but with this enabled, the app uses ~15% of my CPU (on an i3) at idle

assuming "idle" means not pressing any key, why is this KeyPress::eventFilter() being hit at all, let alone loads of times to use that CPU?

mzimmers

@SGaist well, maybe that's my problem -- I'm checking the entire QWidget. (The idea was to reveal hidden buttons when certain keys were pressed.) Given that, I'm not sure there's any meaningful obj parameter checking I can do.

mzimmers

@JonB I suspect I'm doing something wrong with my use of the filter, but I'm not sure what to change. I think my filterEvent() is being called for all events, not just for key events.

JonB

@mzimmers said in using QKeyEvents:

I think my filterEvent() is being called for all events, not just for key events.

I suspect that is more like it ;-) I would worry about that before anything else :)

Use a debugger or qDebug()s to at least see when your filter is being hit, when the user isn't doing anything?

mzimmers

@JonB

    qDebug() << QTime::currentTime().toString();

Got about 6000 hits in ~2 seconds of run time. That explains the CPU usage.

I have no idea what could possibly be generating that many events, though.

JonB

@mzimmers
Start by debugging out ev->type()!

mzimmers

@JonB the great majority were:

QEvent::UpdateRequest
QEvent::Paint

UPDATE: I managed to eliminate the flood of events, but...that didn't have an effect on my CPU usage. The problem is definitely in the KeyEvent class -- when I comment it out, CPU usage is nil. Anyone have any ideas?

mzimmers

Update on this, documented here

The behaviour is different because clicked is emitted on button down on macOS, but on button up on the other two[Windows and Linux]. While the keyboard keys are down, the QPushButton stays down. That's a UX difference caused by how the OS itself behaves.

So, my idea for using the keys goes out the window...I'll think of something else.

The performance issue is a mystery, but I'm going to open a new thread on that. Thanks to everyone for looking.