Fixing Rerun's Visible Time Range: A Deep Dive Into 0.27.3

Understanding the Visible Time Range Problem in Rerun-IO

Hey there, data enthusiasts and Rerun-IO users! What's up, guys? If you've been working with time series data and visualizing it with the awesome Rerun-IO platform, you know how crucial it is for your visualizations to be spot-on. We're talking about making sure your data appears exactly how you expect it, especially when dealing with dynamic elements like the visible time range. Recently, there's been some chatter and a specific bug report about the visible time range feature not quite hitting the mark in the latest Rerun-IO release, version 0.27.3. While some fixes were definitely implemented, it seems like we're still seeing a hiccup, particularly with the x-axis scaling. This article is gonna take a deep dive into this issue, break down what's happening, what was expected, and how we can all navigate it. So, buckle up, because we're about to explore the ins and outs of this Rerun-IO bug, understand its impact on your data visualization workflow, and highlight the importance of precise time-series plotting. We'll be looking at how versions 0.26.2, 0.27.2, and 0.27.3 compare, giving you the full picture.

Alright, let's kick things off by really digging into what the visible time range is all about in Rerun-IO and why it’s such a big deal for us. Imagine you're tracking a sensor's readings over time – maybe temperature, pressure, or the movement of a robot. You're logging tons of data points, but when you look at the graph, you don't always want to see everything from the beginning of time. That's where the visible time range comes in, guys. It's designed to let you focus on a specific, often recent, window of your time series data. For example, you might only want to see the last 3 seconds of data to analyze real-time performance or debug a recent event. This feature is super powerful for maintaining clarity and preventing overwhelming graphs, especially in streaming data scenarios.

Now, here's the rub. In the recent Rerun-IO release, specifically version 0.27.3, a bug fix was implemented that aimed to resolve some visible time range issues. And to its credit, part of it did get fixed! The actual line representing your data points within the specified interval now correctly adheres to that visible time range. That’s a win! But, and this is a pretty significant "but," the x-axis range – the horizontal scale that shows you when these data points occurred – doesn't seem to be playing along properly. Instead of dynamically adjusting to only show that neat 3-second window, it might still display a much broader or incorrect range, making it tough to interpret what you're seeing. This disconnect between where the data appears and what the axis labels indicate can be really misleading when you're trying to quickly grasp trends or anomalies.

Think about it: you've set up your Rerun blueprint to show you precisely the last 3 seconds using a cursor-relative time range, expecting the graph to scroll smoothly, always framing those recent moments. This dynamic view is absolutely essential for applications like robotics, real-time telemetry, or any system where you need immediate feedback. When the x-axis doesn’t adapt, it's like looking through a window where the glass is clean, but the frame is too wide, showing you a lot of irrelevant stuff around the edges. It undermines the very purpose of a focused time range and forces you to manually inspect or guess the actual time context, which isn't ideal for efficient debugging or data analysis. We’ve seen older versions, like 0.26.2, handle this beautifully, providing that expected synchronized behavior where both the data line and the x-axis range move in perfect harmony. However, in 0.27.2, both the line and the x-axis had issues, and while 0.27.3 fixed the line, the x-axis display is still stubbornly clinging to its own broad interpretation. This makes understanding subtle changes in your time series plots much harder, effectively reducing the "at-a-glance" value of your Rerun visualizations. So, while progress has been made on the data visibility front, the x-axis display remains a critical area for improvement to deliver that truly seamless and intuitive Rerun-IO time series experience we all count on.

Diving Deep: Reproducing the Rerun-IO Visible Time Range Issue

Alright, now that we've got a solid grasp on what the problem is, let's roll up our sleeves and see how we can reliably reproduce this visible time range bug in Rerun-IO. This is super important because having a clear, minimal example helps the Rerun development team pinpoint the exact cause and slam-dunk a fix. Our buddy who reported this issue cooked up a fantastic little Python script that does just that, and we're gonna walk through it piece by piece, so you guys understand exactly what's happening under the hood.

The script starts off with some standard Python imports: argparse for handling command-line arguments (like where our Rerun viewer is), math for generating some simple sine wave data, and time for managing our timestamps and logging frequency. Of course, the stars of the show are rerun as rr and rerun.blueprint as rrb – these are our tools for interacting with the Rerun-IO ecosystem and defining our visualization layout.

import argparse
import math
import time
import rerun as rr
import rerun.blueprint as rrb

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("addr")
    args = parser.parse_args()

    rr.init("test_time_series_view")
    rr.connect_grpc(url=f"rerun+http://{args.addr}/proxy")
    blueprint = rrb.Blueprint(
        rrb.TimeSeriesView(
            origin="scalar",
            time_ranges=[
                rrb.VisibleTimeRange(
                    "timestamp",
                    start=rrb.TimeRangeBoundary.cursor_relative(seconds=-3.0),
                    end=rrb.TimeRangeBoundary.cursor_relative(),
                ),
            ],
        ),
        rrb.BlueprintPanel(state="collapsed"),
        rrb.SelectionPanel(state="collapsed"),
        rrb.TimePanel(state="collapsed"),
    )
    rr.send_blueprint(blueprint)
    for step in range(400):
        time.sleep(0.02)
        rr.set_time("timestamp", timestamp=time.time())
        rr.log("scalar", rr.Scalars(math.sin(step / 10.0)))

After setting up the argparse to connect to our Rerun viewer (you’ll run this script and point it to your running rerun process), the magic really begins. We initialize Rerun with rr.init("test_time_series_view") and connect to the viewer using rr.connect_grpc. This establishes the communication channel for our time series data.

The core of our visualization configuration lies within the rrb.Blueprint. This is where we tell Rerun exactly how we want our data displayed. Here, we're creating an rrb.TimeSeriesView. We assign its origin to "scalar", which means this view will display the data we're logging under the "scalar" entity path. This is crucial for linking our data to its visualization.

Now, pay close attention to the time_ranges parameter inside rrb.TimeSeriesView. This is the superstar we're investigating for the visible time range problem. We're defining a single rrb.VisibleTimeRange for the "timestamp" timeline. And here's the clever bit: start=rrb.TimeRangeBoundary.cursor_relative(seconds=-3.0) and end=rrb.TimeRangeBoundary.cursor_relative(). What this mouthful means is, "Hey Rerun, I want my view to start 3 seconds before the current time cursor and end exactly at the current time cursor." This setup is supposed to give us a continuous, sliding 3-second window of our time series data. It's designed for that real-time, "just show me the latest bits" experience that is so vital in many data logging applications. We also collapse some panels (BlueprintPanel, SelectionPanel, TimePanel) to keep the viewer clean and focused on our time series plot. After defining this blueprint, we send it to the Rerun viewer using rr.send_blueprint(blueprint).

Finally, we enter a loop that runs 400 times. In each step, we introduce a small delay with time.sleep(0.02) to simulate data coming in over time. More importantly, rr.set_time("timestamp", timestamp=time.time()) updates our timestamp timeline to the current system time. This is how Rerun knows when each data point occurred. And then, rr.log("scalar", rr.Scalars(math.sin(step / 10.0))) logs a simple sine wave value to the "scalar" entity path. This continuous stream of scalar values over our "timestamp" timeline is what should be neatly confined to our 3-second visible time range. By running this script with a Rerun viewer, you'll clearly see the visible time range bug in action, observing how the line behaves versus the stubborn x-axis scaling in version 0.27.3. It’s a pretty straightforward way to confirm the issue and understand its practical implications for time series visualization in Rerun-IO.

What We Expected vs. What We Got: Rerun-IO Visualization Comparison

Alright, guys, this is where the rubber meets the road! We've talked about the problem, and we've walked through the code that reproduces it. Now, let's visually compare what we expected to see with what we actually got when running our example in different Rerun-IO versions. This comparison is absolutely critical for understanding the impact of this visible time range bug and appreciating why it's such a pain point for precise time series data visualization.

Let's first imagine the expected behavior. The gold standard here is what we saw in Rerun-IO version 0.26.2. Picture this: as the sine wave data streams in, your Rerun viewer shows a beautiful, continuously scrolling graph. The most important thing? Both the data line and the x-axis itself are perfectly synchronized. You define a visible time range of, say, the last 3 seconds, and boom – the graph window consistently displays only those last 3 seconds. The x-axis labels dynamically adjust, always showing you the exact start and end times of that 3-second window relative to the live cursor. This creates an incredibly intuitive and real-time monitoring experience. You can quickly glance at the plot and immediately understand the recent behavior of your scalar data because the visual frame perfectly matches your specified temporal focus. It’s fluid, it’s precise, and it gives you confidence in your data interpretation. When you're debugging, that kind of clarity is invaluable, letting you spot trends, spikes, or drops without having to mentally re-scale the graph. The video for 0.26.2 vividly demonstrates this: a clean, consistent 3-second window, with the x-axis adapting seamlessly to the incoming timestamp data.

Now, let's talk about the actual behavior, specifically in Rerun-IO version 0.27.3. This is where things get a bit wonky. Remember, the Rerun team did implement a bug fix for the visible time range. And true to their word, the data line itself now is correctly limited to the specified 3-second interval. So, you won't see data points stretching far beyond your desired window. That's a definite improvement over version 0.27.2, where both the line and the x-axis were showing erratic behavior, often displaying a much larger range than requested. However, in 0.27.3, even though the line is behaving, the x-axis range is still not set correctly. The video for 0.27.3 clearly illustrates this: while the sine wave stops rendering beyond the 3-second mark, the x-axis itself might still show a much broader range (e.g., 10 seconds or more), or it might zoom out and then snap back, or just not consistently maintain the specified 3-second width. This creates a visual dissonance: you see only 3 seconds of data, but the labels on the x-axis suggest a wider timeframe, making it harder to accurately gauge timing and duration without close inspection.

This mismatch in Rerun-IO visualizations is more than just an aesthetic issue; it has significant implications for data interpretation. If your x-axis isn't accurately representing the visible time range, you might misjudge the rate of change, the duration of an event, or the precise timing of critical incidents. For engineers and data scientists relying on Rerun for rapid debugging and analysis, this can introduce frustrating delays and potential errors. It means that while the visible data might be what you want, the contextual information from the axes isn't aligning, forcing extra mental effort to reconcile what you're seeing. The goal of rrb.VisibleTimeRange is to provide that immediate, accurate temporal context, and until the x-axis fully complies, we’re still missing a piece of that puzzle. We’re definitely seeing progress from 0.27.2 to 0.27.3, but nailing that x-axis consistency is the next big step for a truly flawless visible time range experience in Rerun-IO.

The Impact of X-Axis Mismatches on Data Interpretation

As we just discussed, the visual mismatch caused by the x-axis not properly adhering to the visible time range can severely hamper effective data interpretation. In many fields, especially robotics, finance, or real-time control systems, every millisecond matters. When your time series plots show an elongated or inconsistently scaled x-axis, it makes it incredibly difficult to accurately perceive the duration of events or the rate at which certain values are changing. You might mistakenly assume a process is slower or faster than it truly is, leading to incorrect diagnostic conclusions or misinformed decisions. This lack of precise x-axis scaling means that the very visual cues designed to aid analysis are instead creating confusion, ultimately reducing the overall utility and trustworthiness of the Rerun-IO visualization for critical tasks. Accuracy in these time series plots is paramount for making confident, data-driven decisions.

Getting Your Rerun-IO Setup Ready: A Quick Guide

Alright, future Rerun-IO gurus, if you're itching to experience this visible time range issue firsthand (or just want to get your Rerun environment up and running for all your data visualization needs!), let me walk you through setting up your Rerun-IO setup. It’s pretty straightforward, even if you’re a beginner, and getting this foundational knowledge is key to leveraging Rerun’s full power for time series data.

First things first, you'll need Python installed on your system. Most modern operating systems come with Python pre-installed or make it super easy to install. Once Python is ready, the next step is to install the Rerun Python SDK. This is done through pip, Python's package installer. Just open up your terminal or command prompt and type:

pip install rerun

This command will fetch and install the latest stable version of the Rerun SDK, giving you access to all those rr and rrb modules we talked about earlier. Easy peasy, right? This is the backbone for sending all your time series data, images, 3D models, and anything else you want to visualize into the Rerun viewer.

Next up, you need the Rerun viewer itself. This is the application that actually displays your data. You can download pre-built binaries for your specific operating system (Windows, macOS, Linux) directly from the Rerun-IO website or GitHub releases page. Once downloaded, simply run it. For instance, on Windows, it might be an .exe file; on macOS, a .dmg or application bundle; and on Linux, a binary you execute. When you launch the Rerun viewer, it will typically open up and wait for connections. Pay attention to the address it provides, as you'll need that for our Python script. Often, it will listen on localhost:9876 by default.

Now, let's tie it all together with our reproduction script. Remember that parser.add_argument("addr") part? That's where you'll tell your Python script where to find your running Rerun viewer. So, once your Rerun viewer is happily humming along, open a new terminal or command prompt window. Navigate to the directory where you saved our Python script (let’s call it reproduce_time_range_bug.py). Then, you'll execute it like this:

python reproduce_time_range_bug.py localhost:9876

Replace localhost:9876 with the actual address your Rerun viewer is listening on, if it's different. As soon as you run this command, your Python script will connect to the Rerun viewer, send over the blueprint that defines our TimeSeriesView with the specific VisibleTimeRange settings, and then start streaming that scalar sine wave data. You should immediately see the scalar plot appear in your Rerun viewer, and that's when you can observe the visible time range bug in action. You'll witness the data line correctly clipping, but the x-axis behaving in that slightly uncooperative way we discussed. This Rerun-IO setup is a perfect way to not only verify the bug but also to familiarize yourself with how to interact programmatically with Rerun, which is a fundamental skill for anyone doing serious data visualization and debugging with this powerful tool. Getting this environment configured correctly is your first step towards mastering time series analysis within the Rerun ecosystem, and even when a bug exists, understanding how to trigger and observe it is a key part of the debugging process.

System Specifics: Rerun-IO on Windows and Ubuntu

It's always good practice to note the environment where these issues pop up, right? For this particular visible time range bug, our buddy who reported it was running the Rerun viewer on Windows 11 23H2. Meanwhile, the Python script generating the data and sending it to Rerun was executed on Ubuntu 22.04. This cross-platform detail is actually pretty important, guys, because it tells us that the issue isn't tied to a specific operating system for the data source or the viewer, but rather seems to be a core behavior within the Rerun viewer's time series visualization logic itself. Understanding these system specifics helps the Rerun development team narrow down where to look for the bug, ruling out OS-specific display quirks and focusing on the shared rendering pipeline or blueprint interpretation. It reinforces the idea that this is a Rerun-IO bug that likely affects users across different environments.

What's Next for Rerun-IO Visible Time Range? Community and Solutions

Alright, folks, we've dissected the Rerun-IO visible time range bug from every angle – what it is, how to reproduce it, and the difference between what we want and what we're getting. So, what's the game plan now? How do we move forward and help get this crucial time series visualization feature working flawlessly? This is where the amazing Rerun-IO community truly shines and where collective effort can lead to powerful solutions.

First and foremost, if you're encountering this visible time range issue yourself, or even if you're just nodding along because you rely on accurate time series plots, the best thing you can do is engage with the Rerun-IO project. The original bug report, which this article is based on, is a fantastic example of a clear, concise, and reproducible issue description. Head over to the Rerun-IO GitHub repository and look for existing issues related to the visible time range or x-axis scaling. If you find a similar report, give it a 👍 reaction! Upvoting helps the Rerun team prioritize which bugs are affecting the most users. If you have additional information, screenshots, or even different ways to reproduce the bug, don't hesitate to add comments to existing issues. Your input, no matter how small it seems, contributes valuable context and helps accelerate the debugging process. The more data points (pun intended!) the developers have, the faster they can pinpoint the root cause and roll out a fix that benefits everyone in the Rerun community.

While we wait for an official fix, are there any immediate workarounds or strategies we can employ to minimize the impact of this x-axis mismatch? Unfortunately, for a problem specifically related to the blueprint's display logic, direct workarounds within your Python script for dynamic x-axis scaling are limited if the viewer isn't cooperating. One temporary approach, if your specific visualization needs allow for it, might be to manually adjust the time range in the Rerun viewer UI after the data starts flowing. This isn't ideal for automated setups but can provide a quick sanity check for immediate analysis. Another (less flexible) option might be to hardcode rrb.TimeRangeBoundary.absolute() values for start and end if you are analyzing a fixed time window, but this defeats the purpose of a cursor-relative visible time range for live data. In some scenarios, you might consider logging additional entities that provide explicit time markers or using a different visualization tool temporarily if the x-axis precision is absolutely critical for your current task and Rerun's default behavior is hindering it too much. However, the ultimate solution will come from the Rerun development team addressing the underlying rendering logic.

Looking ahead, the Rerun team is generally very responsive and committed to building a robust visualization platform. Community involvement through bug reports, feature requests, and discussions on their forums or Discord channel plays a huge role in shaping the tool's evolution. So, keep an eye on their official release notes and GitHub discussions for updates on the visible time range fix. The journey from identifying a bug to deploying a solution is a collaborative one, and by staying engaged, we can all contribute to making Rerun-IO an even more powerful and reliable tool for all our data visualization and debugging needs, especially when it comes to those tricky time series plots where every second counts! Let's keep working together to ensure Rerun delivers that consistently precise and intuitive experience we all want.

Conclusion

So there you have it, folks! We've taken a pretty thorough look at the visible time range bug plaguing Rerun-IO versions 0.27.3 and its predecessors. While the team has made commendable strides in getting the data line to respect our specified time window, that pesky x-axis is still giving us a bit of trouble, refusing to dynamically adjust its range as smoothly as it should. We've seen how this mismatch in visualization can really throw a wrench into our time series data analysis and debugging efforts, making it harder to interpret fast-moving data correctly. We walked through the exact Python code to reproduce this, highlighted the clear difference between the expected behavior of 0.26.2 and the current state, and discussed setting up your Rerun environment. The good news is that Rerun-IO is an incredible platform with an active development team, and issues like this are often resolved swiftly with community input. So, keep those bug reports coming, keep engaging with the project, and let's all look forward to a future where our Rerun time series plots are perfectly synchronized, giving us that crystal-clear, accurate data visualization we rely on! Your contributions are what make Rerun-IO better for everyone.