Qt World Summit: Register Today!

[Qt5.1] Emitting many signals (e.g 400 signals/sec) connected to slots with Qt::QueuedConnection causes mouse button to stop working

  • Hello All,

    I recently upgraded to Qt5.1 (Windows 7, Visual Studio 2012) and suddenly I'm having a strange problem with an application (with Qt4.8 the application worked perfectly). Part of this application is filling a QTableView with data very fast, for example 400 new entries per second. This TableView is a subwindow in an MdiArea, which is the central widget of the main window.

    What happens:
    If this table view is visible and it is showing that data is being added (it will scroll the data etc..), and the user tries to move or resize the main window then the left mouse button will no longer work.
    Even other windows applications (also the taskbar), completely unrelated to my application, do not react to the left mouse button anymore. Key presses and the right mouse button still work fine. Also, the table view still shows data being added i.e. the application did not crash.

    After a ctrl-alt-delete, to open the task manager, followed by an ESC, the mouse button is working again.
    After that I get a lot of "QWindowsBackingStore::flush: BitBlt failed (The handle is invalid.)" messages in the output window of Visual Studio.
    I did a search for this message and found other users reporting this message but I don't know yet if this message has anything to do with my problem.

    I created a small test program that reproduces the problem and it seems that whenever I put a lot of messages in the message queue this problem will occur.
    (I wanted to copy/paste the code here but it was too big (about 9000 characters). Is there another/better way to add the code?)

    I was wondering:
    Is it a bad idea to post so many messages or emit so many signals per second? It could go up to 2000 messages/second or so. In my real application I cannot control how fast data is arriving. I just post a message / emit a signal when I have new data and then the data will be added to the model.
    When adding data to the model I try to do the minimum I need which is basically:
    public slots:
    void insertDataTest() {

    In the real application the data is generated in another thread and inserted in the TableModel using signals/slots with QueuedConnections or using QEvents.

    Does anybody have an idea or suggestion about this?


  • Yes, it is a bad idea to fire off too many messages using this mechamism. It works via the event loop, and if you push too many messages onto the queue, your responsiveness with other events will suffer.

    I'd buffer the changes in your thread to reduce the number of messages per second. Why not instead of sending 400 individual changes message, send a message at most 4 times per second or so with on average 100 changes per message? That will also allow you to do your changes to the table on batches, so it doesn't need to redraw all that often.

  • Thanks for your reply,

    I understand that firing too many messages causes the responsiveness of other events to suffer. I'll try to implement this buffering in our application.

    I'm still wondering about some things though:

    Mouse actions such as selecting items in the QTableView, or resizing/moving the QTableView mdi sub window all work perfectly. All while the table view is receiving data at 1000 messages/second and showing the data while scrolling.

    Only when I try to move or resize the QMainWindow, the left mouse button stops responding completely. And it stops responding for all currently open windows applications including the taskbar, start menu etc..

    And even then the TableView is still scrolling and updating smoothly.

    If other events suffer, wouldn't it also be the case that selecting items and resizing the mdi sub window would suffer? and that the update rate of the table view would drop?

    And why does it also interfere with other windows applications?


  • This "article":http://msdn.microsoft.com/en-us/library/windows/desktop/ms645601.aspx may help clarify how mouse event messages are generated and handled in Windows.

  • Thanks, I'll take a look at that article.

    Any opinions/thoughts on the following?

    • The mouse button stops responding for all currently open windows applications. Not only my application.

    • It only stops responding when trying to move/resize the main window of my application. Other mouse actions, such as selecting items in the table view, work fine.

    • When the mouse stops responding, other events still work fine. The tableview still updates/redraws itself and I see no slowdown.


Log in to reply