[HN Gopher] ImPlot: Interactive plotting library, ImGui style
___________________________________________________________________
ImPlot: Interactive plotting library, ImGui style
Author : aroseunsaid
Score : 110 points
Date : 2023-08-04 14:30 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| eska wrote:
| My scientific programmers with only beginner to intermediate
| python knowledge struggled with libraries for visualization. I
| might recommend the python bindings for this to them..
| djoshea wrote:
| Years ago I wrote an oscilloscope-style monitor for an ATI load
| cell using ImGUI in the early days. This library would have been
| extremely useful. Kudos!
|
| Screenshot:
| https://cloud.githubusercontent.com/assets/77752/5382993/9f6...
| fdkz wrote:
| Impressive! I've made something a lot more hacky and limited for
| simple realtime use cases: https://github.com/fdkz/aniplot
|
| Screenshot of a program that uses this library:
| https://fdkz.net/static/images/20171215-aniplot.png
| shortrounddev2 wrote:
| This is awesome. ImGui is the only native UI library I've seen
| that makes intuitive sense to me. Other things are all bogged
| down in their own frameworks rather than just providing a simple
| interface for people to create UI elements with. I think most
| ImGui users are in game development, so I wonder what kind of
| uses this would be good for. Maybe some debugging information,
| but personally I've never needed aggregate statistics for
| debugging info
| orx wrote:
| I am curious how does caching system works. Efficiently reducing
| the amount of data pushed to the gpu memory on every frame is not
| a trivial task.
| ocornut wrote:
| There's no caching. Most people advocating or theorizing about
| caching haven't measured the performances of dear imgui or
| implot. Computers are incredibly powerful when you don't waste
| their resources.
| TillE wrote:
| Yeah I've experimented with caching vertex arrays in a
| scenario very similar to ImGui. It's gotta be faster when
| there's thousands of frames with zero changes, right?
|
| Turns out, not really. It's very easy to make performance
| _worse_ like this. I 'm sure you can find scenarios where it
| makes sense, but in general it's just not a big deal.
| ToppDev wrote:
| We are using it to plot data in the field of Navigation research.
| The library is extremely easy to use and plots look amazing.
|
| Screenshot: https://i.imgur.com/8Mc04NB.png
|
| Repository: https://github.com/UniStuttgart-INS/INSTINCT
| Solvency wrote:
| Out of curiosity why not...
|
| D3, Domo, Highcharts, Tableau, or dozens of other charting and
| dashboarding options?
| dwrodri wrote:
| Full disclosure: I'm a software performance nerd who is building
| a deeper understanding of hardware using whatever tools are
|
| I work with a lot of assembly traces emitted from CPU sims in
| Verilator. These traces can be several gigabytes in size, with
| tens of millions of entries. I've found the typical interactive
| matplotlib backends to not work the best with tens of millions of
| points on my M1 Macbook Pro. This is no slight against
| Matplotlib, or cairo, or agg, or the default macOS backend--they
| prioritize cross-platform "It Just Works" support over extreme
| performance.
|
| But it _does_ irk me that there seems to be such a gap between
| the amount of data we can visualize in the gaming domain in
| comparison to the scientific domain[1]. The difference between 50
| million and 5 billion is 100X. I 'd be ecstatic if I could get
| within 10X difference. I understand that this gap exists for lots
| of reasons, of which I'd be happy to hear in detail in the
| replies to this comment.
|
| 1:https://youtu.be/eviSykqSUUw
| thadt wrote:
| Game engines spend a whole lot of work to _not_ draw things.
| Even if you have an 8K monitor, that 's still only around 33
| million pixels. If the data set you want to visualize is 5
| billion elements, and if you decided that you were going to use
| every single pixel on the screen, you'd still have to collapse
| those 5 billion elements in a visual space of less than %1 the
| size.
|
| In a video game it's easy to figure out what not to show - just
| hide everything that would normally be too small or far away to
| see. But in a scientific domain, what to show and what to hide
| might be a much more interesting question.
|
| On the other hand, if you're just looking for a plot of a few
| billion elements with the ability to zoom in and out, then a
| straightforward decimation of the data and drawing it to the
| screen can work. In the past I've written custom tools to do
| just that, but at this point in life I would probably throw it
| at something like SciChart and let it take care of that.
| semi-extrinsic wrote:
| Have you tried holoviews with datashader?
|
| https://holoviews.org/user_guide/Large_Data.html
| blondin wrote:
| these demo charts look very good! and it seems like ImGui makes
| animation and effects easy to integrate. styling and theming
| charts are always a pain.
| applied_heat wrote:
| I have been a heavy user of KST for interactive and real time
| plotting but will definitely check this out!
| wdfx wrote:
| > avoids STL containers
|
| I'm not sure I fully understand why some projects so proudly
| avoid using standard library features and e.g. favour a more
| manual approach to memory/data management. What are some good key
| reasons for this?
|
| > avoids ... C++ headers
|
| Same question for this point - but is it the same reason as for
| avoiding STL containers or something else?
| _gabe_ wrote:
| >> avoids ... C++ headers
|
| > Same question for this point - but is it the same reason as
| for avoiding STL containers or something else?
|
| ABI compatibility and the ability to easily create FFIs for
| other languages are the strongest appeals afaik.
| [deleted]
| dundarious wrote:
| Sprinkling small malloc and free-s everywhere, where every
| object has their own individual lifetime to be managed, is very
| often not the best approach. Using STL containers often means
| using that prolific allocation strategy -- it just makes the
| numerous small allocations implicit. A region based approach is
| often far simpler conceptually, and more performant. This is a
| decent article on the topic:
| https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...
|
| C++ is a big language and there is a lot of diversity of
| opinion in what a sensible subset of the language is, with
| numerous concerns influencing those decisions -- one common one
| is compile times. Using C only headers generally ensures a much
| lower ceiling for compile times compared to using typical C++
| headers. And C++ headers are slightly more likely to use the
| prolific allocation strategy from above. As such, C++ headers
| require far more scrutiny before acceptance, in my view.
| corysama wrote:
| C++ compiler inlining capabilities have had to become magically
| powerful to keep up with the layers of small functions under
| every STL container method. Meanwhile, in some applications
| (games) high performance in debug builds is necessary.
|
| Same for headers, compile times matter. I'm very much looking
| forward to widespread, fully-modulized standard libraries.
| turtledragonfly wrote:
| Historically, in high-performance resource-constrained
| applications (eg: console video games), developers would use a
| "stripped down" version of C++ (eg: no RAII, no exceptions),
| which often included avoiding STL. It's less true these days,
| but still somewhat. In truth, STL will _never_ be fully
| catering to these uses; that 's not its goal.
|
| One reason STL was avoided is that control over memory
| allocation was quite poor. std::allocator was somewhat
| conceptually broken for a long time, only recently remedied in
| C++14 and 17. So, there's still about 20 years of code out
| there from the days of old bad C++ (:
|
| Another reason is that early STL implementations were poor, and
| not well-suited to high-performance use cases. Again, this has
| gotten better (some), but the legacy lives on.
|
| Here's a good one to read:
| https://github.com/electronicarts/EASTL/blob/master/doc/Desi...
|
| So, if you are designing a library to be used in video games
| (such as in TFA), and want wide adoption, then avoiding STL,
| RAII, exceptions is still generally a good idea, IMO.
| dan-robertson wrote:
| STL also has some kinda broken features, eg it's hard to work
| with a std::vector<T> because everything is different when
| T=bool and then you get confusing errors if you happen to do
| that accidentally. std::vector<char> is also a bit broken
| though that's the language's fault rather than STL's.
| flohofwoe wrote:
| One important reason is compile time. C++ stdlib headers are so
| entangled which each other that each one brings in tens of
| thousands of lines of complex template code, which may increase
| the compilation time for a single source file to seconds, and
| it's getting worse with each new C++ version.
|
| Also, it's not like writing your own growable array is rocket
| science, and a simple, specialized version can be done in a few
| dozen to a few hundred lines of code.
| wthomp wrote:
| I'm using this from Julia and both the user and developer
| experience is great. It's much more limited than publication
| style plotting libraries but the instant 60fps reactivity is
| amazing.
___________________________________________________________________
(page generated 2023-08-04 23:01 UTC)