Bug 627 - Corrupted timescale shown when zooming out (max) and then in (max)
Summary: Corrupted timescale shown when zooming out (max) and then in (max)
Status: RESOLVED FIXED
Alias: None
Product: PulseView
Classification: Unclassified
Component: Data display (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-21 18:53 CEST by Uwe Hermann
Modified: 2015-09-04 15:10 CEST (History)
1 user (show)



Attachments
Screenshot of zoom issue (16.04 KB, image/png)
2015-08-21 18:53 CEST, Uwe Hermann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Hermann 2015-08-21 18:53:27 CEST
Created attachment 148 [details]
Screenshot of zoom issue

PulseView shows a corrupted timescale (see attached screenshot). How to reproduce:

 - Start PV, no devices attached, demo is autoselected.

 - Use the scrollwheel to zoom out until you cannot zoom further.

 - Use the scrollwheel to zoom in until you cannot zoom further.

When zooming in the timescale will eventually corrupt.

This is reproducible on Linux with Qt5 and on Windows with Qt4 so I'm somewhat confident that it isn't my specific system or window manager or something like that.
Comment 1 Soeren Apel 2015-08-23 12:18:55 CEST
The issue here is that several variables dealing with floating-point time values using doubles are losing their precision. The large view offset caused by zooming out doesn't leave enough bits to represent the fractional part with the precision that we need. As a result, calculations go haywire.

This is something that has no short-term fix, so I went ahead and limited the max zoom level to 100 ps, where everything works well as long as the measurement isn't much longer than about 24 hours. I think that's a plausible compromise.

Looking into this also revealed a subtle bug in the time formatting algorithm that is now fixed.
Comment 2 Uwe Hermann 2015-08-25 19:01:22 CEST
Thanks, the short-term fix is merged as 818f617924d2ed393cadd362fdafbd9d4288848f.

The other unrelated fix you mentioned is merged as ca810a8ce1f0257e78ad00bc8f794c68f7438cad.

Leaving the bug open though since the issue is not entirely fixed, yet.
Comment 3 Uwe Hermann 2015-09-04 15:10:45 CEST
Fully fixed in 60d9b99a32e551cffd2b537d3e157d578a761c9b, thanks!