https://doc.qt.io/qt-6/qabstractitemmodel.html#data
If my data has high latency to access, how can I tell Qt to call QAbstractItemModel::data() again later?
Related
I am working with a CAN application and am having some timing issues. It seems there is some time delta between when my CAN message write function completes and when the CAN message is actually transmitted. So I want to measure the time between the two. The write function is in C++, so it's a simple call to GetTickCount to know when the write function completes. It's knowing when the actual transmission happens that's the problem.
I am using Vector's CANalyzer to monitor my CAN bus, and heard it has a programming interface (CAPL). What I would like to do is grab the PC clock time at which a message has actually been transmitted. Is there any system-CAPL interface that I could use to do this?
It would be easier to measure the time in your C++ program. The CAN driver should provide some "TX confirmation callback function". The CAN driver calls this function as soon as the message has been successfully transmitted. You would need to configure the callback and to measure the time between your CAN write operation and this callback.
Assume a C++ business model which is potentially changing its underlying data very quickly (let's say up to 1000 Hz).
In my specific case, this would be a wrapper around a network data callback mechanism (a ROS-subscriber to be more precise) running in its own thread. Think of the data as some sensor reading. Further assume that we are dealing with simple data, e.g. a single double value or a string in the worst case.
What would be the best way to visualize such data in a QML component? Best here is with respect to being gentle with resources, minimizing the delay between model state and view, and being as clean code as possible?
I came up with the following options:
Bind the data as property of the model to the view, and emit a dataChanged() signal on every update of the data:
Pro: Elegant code, lowest resource usage in case of low data update rates.
Con: High signal frequency will spam the GUI and maximize resource utilization, potentially rendering the system unresponsive.
Use a QML-Timer and poll the model at a specific interval (e.g. 10 - 60 Hz):
Pro: Upper limit on resource utilization, steady rate
Con: Timer itself consumes resources; not as elegant as data binding; if data generation/callback rate is lower than timer rate, unnecessary polling calls have to be made.
Use data binding as in 1. but throttle the signal emitting frequency inside the C++ model using a QTimer (or another timer like boost's), i.e., only emit the dataChanged() signal at specific intervals:
Pro: Same as 2.
Con: Same as 2.
Combine Timer from 3. with some kind of check whether the data actually changed, prior to emitting the signal, thus avoiding unnecessary signal emitting if data has not changed:
Pro: Same as 3.
Con: same as 3. but even less elegant; increased risk to induce a bug because logic is more complicated; model is harder to reuse as the data changed check highly depends on the nature of the data
Did I miss an option (besides not producing so much data in the first place)? What would be your choice or the most QT/QML way of realizing this?
First of all, have you established that there is a performance problem?
I mean granted, 1000 updates per second is plenty, but is this likely to force GUI updates a 1000 times a second? Or maybe the GUI only updates when a new frame is rendered? Any remotely sane GUI framework would to exactly that. Even if your data changes a gazzilion times per second, GUI changes will only be reflected at the frame rate the GUI is being rendered in.
That being said, you could work to reduce the strain on the backend. A typical "convenience" implementation would burden the system, and even if any contemporary platform that Qt supports could handle 1000 Hz for an object or two, if those are many, then you should work to reduce that. And even if not directly detrimental to system performance, efficiency is always nice as long as it doesn't come at a too high cost development wise.
I would not suggest to directly update data using a property or model interface, as that would flood with signal notifications. You should handle the underlying data updates silently on the low level, and only periodically inform the property or model interface of the changes.
If your update is continuous, just set a timer, 30 Hz or even less outta be OK if a human is looking at it.
If it is not, you could use a "dirty" flag. When data changes, set the flag and start the update timer as a single shot, when the timer triggers and notifies the update, it clears the flag and suspends. This way you avoid running the timer without any updates being necessary.
I've used FileSystemWatcher in the past. However, I am hoping someone can explain how it actually is working behind the scenes.
I plan to utilize it in an application I am making and it would monitor about 5 drives and maybe 300,000 files.
Does the FileSystemWatcher actually do "Checking" on the drive - as in, will it be causing wear/tear on the drive? Also does it impact hard drive ability to "sleep"
This is where I do not understand how it works - if it is like scanning the drives on a timer etc... or if its waiting for some type of notification from the OS before it does anything.
I just do not want to implement something that is going to cause extra reads on a drive and keep the drive from sleeping.
Nothing like that. The file system driver simply monitors the normal file operations requested by other programs that run on the machine against the filters you've selected. If there's a match then it adds an entry to an internal buffer that records the operation and the filename. Which completes the driver request and gets an event to run in your program. You'll get the details of the operation passed to you from that buffer.
So nothing actually happens the operations themselves, there is no extra disk activity at all. It is all just software that runs. The overhead is minimal, nothing slows down noticeably.
The short answer is no. The FileSystemWatcher calls the ReadDirectoryChangesW API passing it an asynchronous flag. Basically, Windows will store data in an allocated buffer when changes to a directory occur. This function returns the data in that buffer and the FileSystemWatcher converts it into nice notifications for you.
As stated clearly in the documentation, Qt GUI must be accessed from main thread only. For complex app with multiple large and busy tables, this can be a bottleneck just from all the font-size text metrics calculations Qt likes to do. The only alternative I can think of is multi-tasking with separate processes. The tables are currently about as fast as you can get, custom model that is direct-mapped to a cache that is fed from another thread using dataChanged() calls on the most conservative set of changed cells. I've already profiled with vTune, 70% of the app time is now in Qt rendering code. Any suggestions?
I havn't used QT, but accessing GUI from only one thread (the GUI thread) is a known matter in almost any GUI I'm familiar with. I used 2 solutions for this case, of which I prefer the first one:
1) Your form will update the GUI (table, in this case) at timer intervals. The timer is activated on the GUI thread's events. At those timer events you read the data from global vars and update your table. The global vars can be updated by as many threads as you wish. You might need to synch (semaphores, for examples) the access to the global vars.
2) In many GUI APIs threads can update the GUI by handing the GUI thread a function (or an object) and ask it to execute it ASAP on its context. The calling thread meanwhile blocks, until the GUI fulfilled the action. I can recall three such functions - Invoke, InvokeLater from Java and C#, or wx.CallAfter of wxPython.
Use a variant of MVC pattern and make the model multithread
If your table entries and methods are done in several steps, you can call QCoreApplication::processEvents() to update the qt ui in between the calculations. Another thing you can do is run everything on different thread and emit signals from the thread when the calculations are complete. At the end, the updates are done on the ui from the main thread but asynchronously. To connect to a signal from a different thread you'll have to use qRegisterMetaType<>.
Ours is a huge project. I need to call certain functions in my code asynchronously to avoid some circular function calls. Upon receiving a specific input, I can call my function asynchronously either by using Event or Timer.
Which way is preferable considering Performance ?
Sending events to Event manager and handling them with an Event handler ? Or
Starting a timer and provide timeout handler ?
For pure performance, event-driven model will be better. Use timers only if you cannot rely on one or more of your events to get set in a timely way by the worker code, and so need a backup means by which to continue processing. This may be the case if your worker code makes external calls to a database or other remote service whose reliability or performance is unproven.