Take the Code Example demo initially opened: drag age up to 120, then press the Increment button, and watch the label “Arthur is 120” briefly blip to “Arthur is 121” (while the DragValue still shows 120!) before being dragged back down to 120 presumably by rerendering and egui::DragValue::new(age).range(0..=120) clamping it.
That’s… eww. It probably doesn’t often cause real problems—though it surely could, as it’s allowing temporary rendering with out-of-bounds values that a developer might have expected to be clamped—but it’s still very eww, the idea that mutating data leads to parts of a frame being rendered with different data.
I’m currently on mobile, where I couldn’t reproduce this.
I agree, that shouldn’t happen and it might be a bug, because the input is handled after drawing the initial frame and should be clamped before starting to draw the next frame. Drag events are tricky though, because they come with a frame delay by default (you have to recognize the drag).
Does this reproduce reliably on desktop? If so then I can create an issue for this.
Thank you for linking your project—that looks really cool! I saw you also implemented a pan-and-zoom area. We are currently working on moving Rerun's implementation to egui [0], so maybe keep an eye on that.
It would be super cool to have layered graph drawing in (Sugiyama-style) in Rerun too. The tricky–but super interesting–challenge that we face is that our layout implementations need to be consistent across timestamps if the underlying structure of the graph changes, which is why we initially chose a force-based layout approach. There, the time-varying aspect is handled naturally by the simulation.
The very interactive nature of Rerun also poses more restrictions on the implementation of our algorithms: re-layouts ideally need to be fast, to produce visualizations quickly, especially when scrubbing the timeline.
I still hope we can rid you of some of the todos ;).
Hi, Jochen from Rerun here (@grtlr on GitHub)! I implemented most of the graph view, including Fjädra [0], our Rust port of the excellent d3-force [1].
In the future we want to provide more types of layouts, dataflow is high up on that list. May I ask what kind of data you want to visualize? Since you mentioned Sankeys, in your case does the structure of the Sankey change as well, or do you only expect the edges to grow/shrink over time?
Thank you for your reply. I am thinking about variable dataflows through a fixed set of nodes -- so, the latter, growing and shrinking edges. The application would be visualizing system dynamics. The stages in the Sankey would be organized by degree of distance from an "intervention" node.
That's very interesting! We're currently working on the plumbing to be able to assign attributes to edges as well—right now it's only possible to style/configure the nodes.
Once we have that though, there is another approach that you can take before you go down the path of writing your own visualizer/view: you can also log custom positions for each node. Since the node positions don't change in your case that might get you quite far by statically logging the nodes with a Sankey layout computed by your application.
For us it was a mixture of multiple things: It’s a very mature library that has been stable over the last years and became the de facto standard in web-based visualizations, where—just as in Rerun—interactivity plays an important role. The predefined forces that ship with it make it very flexible and are easily extensible. Finally, having worked with it a fair amount in the past, personal preferences surely played their part as well.
Disclaimer upfront: I have no direct experience with TVM.
I would imagine that the model compilation works quite similar, but I'm not sure if TVM supports palletization.
What I believe is unique to Talaria, is that it can make recommendations for optimizations to the user for each of the layer in the network.
The system allows the user to quickly identify "problematic" layers either through the table view or the graph viewer. This works based on simulated metrics (energy consumption, latency, ...) that are collected for each layers. It then gives optimization choices for each layer, together with the implied changes to the overall (total) metrics. I'm not sure if TVM collects / exposes similar metrics.
So a large part of the system focus on the user-in-the-loop aspect of optimizing a network for inference, which is also why this paper was presented at a conference on human-computer interaction (SIGCHI).
We just released Mycelium, the library that powers Talaria’s graph viewer. You can check it out and play around with it here: https://apple.github.io/ml-mycelium
I’m happy to answer any questions about Talaria or Mycelium!
SEEKING WORK | Heidelberg, Germany | Remote around the world or on-site locally
I am a consulting software engineer and research scientist based in Germany. With a Ph.D. in computer science, I develop visualization systems that help my clients make sense of complex data and machine learning models.
The systems I develop typically leverage a combination of frontend and backend components. Because of this, I have expertise in a wide range of languages and frameworks.
I have more than five years of experience writing efficient and performant systems code in Rust that can also compile to WASM, while I use TypeScript together with frontend frameworks such as Svelte, React, or Vue to provide robust and rich user interactions that are intuitive to grasp for all stakeholders. I love working closely with clients to fully understand the requirements of their business domain—and helping them integrate my work by refactoring or modernizing legacy systems.
I have worked on practical projects in big tech and presented my work at Distill.pub and top academic conferences, winning multiple awards. You can find a full list of publications on Google Scholar: https://scholar.google.de/citations?user=IuSk_rUAAAAJ
This mechanism can get you there most of the time.