QCustomPlot Discussion and Comments

real-time examples hang window interactionReturn to overview

I'm exploring the examples provided in the download and I've come across the plot examples. There are 2 examples which update the graphic in real time using a timer. That timer is set to 0 to update the graph as fast as possible; unfortunately this hangs window interaction and you'll be unable to move the window, to use the close/minmize/maximize buttons, to resize it, or to make any other interaction with it. Moreover it also locks the cursor on the example window so you'll be unable to even touch the taskbar or to interact with any other application (the cursor actually moves, but won't interact with the other windows/applications).
The solution is pretty simple: use a 1 or higher value instead of 0 to start the timer. While with 0 you'll get around 350 FPS or even more, with 1 and higher you'll get to around 60FPS, but window interaction will be responsive as it should be.

This happens on Windows 7 Professional x64 SP1 and QCustomPlot 1.0.1 on Qt 5.1.1 with MSVC2012 x86 compiler (no OpenGL). I'm not sure if it happens on other OSs or Qt versions too, but probably it does.

So, besides the fact that I wanted to let know people of this little issue, I'd also like to understand what's going on? Why does a timer set to 0 hang the window while a simple 1 solves the issue? And why does the framerate drop (on my system) from 374 FPS to 60FPS when switching from timer(0) to timer(1)?

This is very strange behaviour that I didn't see on any of the (many) systems that I've had QCustomPlot running on. Further, it's the first time this has been reported. And as you say, it doesn't realy make sense, since a QTimer with timeout 0 will still only execute once per event-loop, allowing normal interaction with the UI (that's the benefit of using a QTimer with timeout 0 in the first place, compared with an endless while loop or similar).

It looks to me like a Qt 5.1.1 fault, somehow... or maybe a compiler fault? I can't actually understand what's going on behind the scenes. I can think that with a 0 timeout the application is distributing the whole work on all 6 cores of my CPU, while with a timeout higher than 0 it just uses a few or a single core..? I'm not sure that is even possible...

Anyway, I recently "upgraded" my Qt 5.1.1 installation with brand-new MinGW 32 and 64 bit compilers, and I'm going to test again. I'll report as soon as possible.

I'm very sorry for the long time required to reply but I've been a bit busy.
I eventually found that the above issue only happens with the MSVC12 compiler (any 32 or 64 bit version), while the MinGW 4.8.1 compiler creates perfectly running executables.

As I'm not sure whether this is a Qt 5.1.1 fault, or a QCustomPlot fault, or a MSVC12 fault, I have uploaded a zip file containing the compiled EXEs (debug versions) with both MSVC12 and MinGW 4.8.1 compilers (both 32 and 64 bit versions), for debugging purposes. I have also made the effort of writing a complete README.txt file explaining the issues, how to work-around... ect. so please make sure you have a look at it. Unfortunately, the 10 resulting EXEs get quite large all together and the zip file is around 25MB (no deploying DLLs included -only the EXEs- instructions for running the applications are provided in the readme file).

https://docs.google.com/file/d/0B9uTCyb7q8yXRlVMU3FBcjlmYTA/edit?usp=sharing

I am not sure whether to ask about this issue on the Qt forums too, or on the Microsoft forums. I'll first wait for your advice, Emanuel, and just then I may proceed either way. Also, let me know if there's anything else I can do to help you.