RE: [fltk.general] realtime data display [General Use]
35 views
Skip to first unread message
MacArthur, Ian (Leonardo, UK)
Nov 29, 2016, 5:29:47 AM11/29/16
to fltkg...@googlegroups.com
> Using fltk I would like to display images coming asynchronously from a
> separate capture thread (c++11 std::thread, already coded and tested).
> At present I'm doing something similar with wxwidgets. The capture
> thread prepares an entry in a shared ring buffer, then queues a custom
> event which is processed by an event handling function by the main loop.
> What is the right way to do this with fltk?
There is no "right way" per se - displaying asynchronous data is the sort of task for which there is no "universally correct" solution.
It depends too much on data rates, frame rates and all manner of other aspects.
The fltk approach most similar to what it *sounds* like you are doing from your description above might be to have the worker thread send one of the various types of Fl::awake() message, to signal the main GUI thread that there was information to process.
The main thread can then read messages from your queue and decide whether to display them or not.
I'm assuming at this point that you have read the section on threading in the fltk docs and *understand* the constraints that are outlined there?
> Searching for "realtime data display" in this forum gave me mainly the
> following results:
> https://groups.google.com/forum/#!topic/fltkgeneral/-bIjXnLQCL4%5B1-25%5D
> dated 2013,
Yes, this was an interesting one. Much of the info in that thread is possibly useful to you, but it was predicated around the specific task that the Team Prii folks were doing, and the "mistakes" that they had made in their initial coding.
For example, common mistakes are:-
1. They tried to display *everything* that was received, even though their system was updating at a fairly high rate. This is a recurring mistake that many people make.
The bottom line is that your monitor probably only refreshes at 60Hz, and humans won't really comprehend anything you display at faster than about 12Hz, so if you are updating your data at 500Hz, you are wasting your time trying to display it all. Display every 50th frame and be happy.
The canonical example of this is video gamers that rave on about getting 137 FPS in some graphical shooter.
Nope.
They may be updating the internal game state at 137 FPS, but they aren't likely to display any more than 60 FPS unless they have some really exotic display hardware.
Do not make the same mistake.
2. The Team Prii folks wanted to log *all* their data. This is a reasonable target to aspire to, particularly in their use case. However, they had built their logging system and their display system as one entity, so it was awkward for them to discard data from the display without also losing it from their logger.
So if you are in that circumstance, think about how to manage the logging process (at full data rate) as distinct from the display process (which should probably only try to display "enough" of the data to keep the user entertained.)
Anyway, that was an interesting project - I don't know how they got on, but it inspired me to buy a ODB-II USB dongle and build an interface for the Subaru Imprezza I had at the time.
Which I then didn’t actually use much (propping my old 13" laptop on the passenger seat annoyed my wife, for some reason) but hey...
Then I sold that car.
Oh well.
> and
> https://groups.google.com/forum/#!searchin/fltkgeneral/realtime$20data$20display%7Csort:relevance/fltkgeneral/1hdwtbqDtV8/Ra846o0Ct28J
> dated 2014.
Don't remember so much about that thread (and I have not re-read it.)
I have a sense that the OP maybe wasn't really understanding the issues, but perhaps I do them an injustice. It was a while ago...
> Am I missing something more recent?
> Have the long discussions been frozen to an up-to-date manual page /
> example / tutorial?
As noted above, I do not think there is a single, correct, solution.
What is your target frame rate, how fast does your data arrive, what do you *need* to display, etc...
If you can outline more aspects, we might be able to offer some ideas.
> I also found this example from a camera vendor:
> https://www.matrix-vision.com/manuals/SDK_CPP/SynchronousCaptureMultiple
> InputsFLTK_8cpp-example.html
> but I am not sure how much it is to be trusted.
I can't comment on that code. Never seen it and don't have time to study it...
Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
> separate capture thread (c++11 std::thread, already coded and tested).
> At present I'm doing something similar with wxwidgets. The capture
> thread prepares an entry in a shared ring buffer, then queues a custom
> event which is processed by an event handling function by the main loop.
> What is the right way to do this with fltk?
There is no "right way" per se - displaying asynchronous data is the sort of task for which there is no "universally correct" solution.
It depends too much on data rates, frame rates and all manner of other aspects.
The fltk approach most similar to what it *sounds* like you are doing from your description above might be to have the worker thread send one of the various types of Fl::awake() message, to signal the main GUI thread that there was information to process.
The main thread can then read messages from your queue and decide whether to display them or not.
I'm assuming at this point that you have read the section on threading in the fltk docs and *understand* the constraints that are outlined there?
> Searching for "realtime data display" in this forum gave me mainly the
> following results:
> https://groups.google.com/forum/#!topic/fltkgeneral/-bIjXnLQCL4%5B1-25%5D
> dated 2013,
Yes, this was an interesting one. Much of the info in that thread is possibly useful to you, but it was predicated around the specific task that the Team Prii folks were doing, and the "mistakes" that they had made in their initial coding.
For example, common mistakes are:-
1. They tried to display *everything* that was received, even though their system was updating at a fairly high rate. This is a recurring mistake that many people make.
The bottom line is that your monitor probably only refreshes at 60Hz, and humans won't really comprehend anything you display at faster than about 12Hz, so if you are updating your data at 500Hz, you are wasting your time trying to display it all. Display every 50th frame and be happy.
The canonical example of this is video gamers that rave on about getting 137 FPS in some graphical shooter.
Nope.
They may be updating the internal game state at 137 FPS, but they aren't likely to display any more than 60 FPS unless they have some really exotic display hardware.
Do not make the same mistake.
2. The Team Prii folks wanted to log *all* their data. This is a reasonable target to aspire to, particularly in their use case. However, they had built their logging system and their display system as one entity, so it was awkward for them to discard data from the display without also losing it from their logger.
So if you are in that circumstance, think about how to manage the logging process (at full data rate) as distinct from the display process (which should probably only try to display "enough" of the data to keep the user entertained.)
Anyway, that was an interesting project - I don't know how they got on, but it inspired me to buy a ODB-II USB dongle and build an interface for the Subaru Imprezza I had at the time.
Which I then didn’t actually use much (propping my old 13" laptop on the passenger seat annoyed my wife, for some reason) but hey...
Then I sold that car.
Oh well.
> and
> https://groups.google.com/forum/#!searchin/fltkgeneral/realtime$20data$20display%7Csort:relevance/fltkgeneral/1hdwtbqDtV8/Ra846o0Ct28J
> dated 2014.
Don't remember so much about that thread (and I have not re-read it.)
I have a sense that the OP maybe wasn't really understanding the issues, but perhaps I do them an injustice. It was a while ago...
> Am I missing something more recent?
> Have the long discussions been frozen to an up-to-date manual page /
> example / tutorial?
As noted above, I do not think there is a single, correct, solution.
What is your target frame rate, how fast does your data arrive, what do you *need* to display, etc...
If you can outline more aspects, we might be able to offer some ideas.
> I also found this example from a camera vendor:
> https://www.matrix-vision.com/manuals/SDK_CPP/SynchronousCaptureMultiple
> InputsFLTK_8cpp-example.html
> but I am not sure how much it is to be trusted.
I can't comment on that code. Never seen it and don't have time to study it...
Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Reply all
Reply to author
Forward
0 new messages