16

Improve Bubble Text Formatting, Merging, and Display


Avatar
Tim

Let us know any feedback you have as to how we can improve displaying decoded bubble text! We would like to consolidate all feedback in this feature request post as comments below.


Original request below:

A downside of bubble merging is that the underlying data can be misread while zoomed out.

When there are too many entries inside a bubble, it will simply read from left to right sequentially, without skipping any data. This causes misinterpretation as in the image below.

Zooming in will read the data correctly.

Potential Solution: I would propose that when zooming out of larger patterns, for example a repetition of the same character a β€œbreak” symbol is shown:

(See wavedrom.png attached).

Also the number of repetions could be shown in a bubble, just like the one visible on your screenshot : 0xFF (x42), or if more than 99: 0xFF (+99).

If the pattern is not a repetition, I would just skip the data and show some kind of symbol. β€˜πŸ”Žβ€™ or β€˜β€¦β€™ as long as they do not fit.


A

Activity Newest / Oldest

Avatar

Tim

(#86148)
"When zoomed in the actual data in the selected format is properly shown. And when all zoomed out, a good effort is also made to show the data. But in between those extreme zoom levels the data view is cropped."


Avatar

Tim

discuss.saleae.com/t/remove-frames-spanning-on-multiple-channels-for-custom-analyzer/2373
"when I zoom out, the frames without text merged with the frames with text, making for a very confusing display. Any ideas on how to fix this ?

Here is a screenshot of what it looks like in Logic"


A

When there are large gaps between bytes, it would be nice to widen the analyzer output in the display. e.g. here is a capture with a 3 mbaud UART, but with ~100 us between each byte. The protocol output is unreadable in the timeline.


Avatar

Tim

Merged with: Widen protocol analyzer output

Avatar

Tim

(#68064)
"Hi, I wanted to tell you about what I think is a regression in Logic 2 v2.3.45

In the attached screen shot you can see a few very short SPI data blips around 0.3ms and 0.67ms. The problem is that you can't read any values. In the past, there would be a minimum width and you could see the value of that data. Now, it's just a vertical line with no visible values.

I think you need to display a minimum width, or minimum number of bytes. Or just go back to how it used to be in earlier versions. This might not seem like much, but as you can see that display is essentially useless for reading that data. To get to the values requires zooming or switching to the data table, which is a really huge pita.

Hoping you understand the issue from my rambling description and can fix it to show some data!"


Avatar

Tim

"As far as minimum widths go, I meant instead of a 2 pixel slice it should show some minimum number of bytes, eg 2 or variable if there is space. In my screenshot there is plenty of space to do this. I have a feeling that some bug is making your code believe there is no space. Right now it's super awkward to use, you have to zoom in 1000x to see the data (or jump to the table) for every such byte.

To clarify, by space I mean space between subsequent packets, whereas I think you are basing it on the width of the current packet. Using the current packet will guarantee you always have that mush space without overlap, but it's useless for zoomed out data. Using the space b/w packets as well gives you more room, but again, it might be hard to compute this (though not really - it should know where each block starts)"


M

Mark

Thanks for adding this Tim.
~Mark


Avatar

Tim

(#66359)
"Not sure if it should be considered a bug but as seen in the SPI data above, there's more than enough room to fully display the bytes but instead, the byte "box" is very small making it difficult to see the value of multiple consecutive bytes. I'd understand if the bytes were very close altogether but as seen in this screenshot, it is not the case and I think each byte should be fully visible."


Avatar

Tim

(#60106)
"I would like to see the decoded data text boxes take up as much room as possible, to display as much of the data as possible. At this zoom level, the text boxes are only large enough to display "0x", but there's unused blank space for them to be expanded and show at least the first few nibbles. Thanks for you consideration."


Avatar

Peter Jaquiery

At present (2.2.8) analyzer output (Async serial at least) text in bubbles and the terminal quote spaces which clutters the output making it harder to read. In the terminal rn is shown as text instead of causing a line break. Combined these make interpreting log type output harder than it needs to be.

Depending on zoom analyzer strings are too aggressively shortened. Filling the available space would make it easier to see output.

(update:) Just noticed the popup when hovering over a bubble. Love it, but it too could be less aggressive truncating strings.


Avatar

Tim

Merged with: Declutter and fill analyzer output

C

Chris

Hi,
it would be great if there were the possibility to change the font-size of the analyzer bubbles globally in the general settings and also in the analyzer options in order to change it for specific analyzers.
Additional settings that would be nice to have: font weight, font family (monospace or non-monospace), color.


Avatar

Tim

Merged with: Bubble font settings

Avatar

Tim

(#59824)
[Note: Feedback here is to improve the way bubble text is pinned to either the left or right of the bubble box]

"Bug Report - Bubble text pins to left edge of trace instead of right edge of bubble."


Avatar

Tim

See full discussion here:
discuss.saleae.com/t/logic-2-3-20/950

"Great to see more characters in bubbles, but there is still the major (in my mind) issue of not using the bubble real estate correctly as zoom increases:"


Avatar

Tim

(#55298)
"The SPI miso line writes 0xFF but it is absolutely not 0xFF but 0x00. This happens when zooming out. When zooming in the values overlayed are correct"


A

Adrian

The data display is so much better than it used to be, but it's frustrating to have the packet truncated with "..." when there is still space for the whole thing. Just pick the truncation point so that all the space in the the bar is used, and I'll be a happy camper.