google
Allow viewing long logcat messages in Perfetto UI
Currently logcat viewer truncates long logcat messages, and I can't seem to find a way to see the whole message:
The message column is resizable but I can't see the whole message if it doesn't fit into screen width.
Maybe we could make it show the whole message when double-clicking on the cell, or add an option to wrap message string to fit into cell?
You can double click on the column resize handle to auto fit the column to the cell contents, a la excel.
Columns actually do auto fit on startup but there's a max limit of 600px to avoid awkwardly wide tables, but the double click auto resize has no limit (well a much larger limit which I was thinking of removing anyway TBH).
Wrapping is hard because we use virtual scrolling so all rows have to be the same height.
Let me know if the double click column auto size works, otherwise we could do some sort of pop up for overflowing cells perhaps - like track names.
Thank you, Steve! I have tried double clicking on the resize handle, it expands the column but it seems it is still limited to the screen width (or some other limit?).
See screenshot:
If the message is too long, it is still truncated with '...' and I couldn't find a way to get the full text. Every time I need to see the whole text I have to use the chrome devtools :(
I'm not sure if track name-like popup would work well as it's not copiable, maybe showing a persistent selectable multiline popup when double-clicking on a cell might work better?
Personally, I would prefer multi-line wrapped rendering of all messages at once, even if it will hurt performance. Not sure if it would make sense at least to have an option for this.
Here are a few issues that I consistently have with the current log viewer:
- I find that often log messages are quite long and I would like to see/copy part of them
- common use case for this is stacktraces: currently it's almost impossible to read them as they are quite long and multiline
- I often select text in some line of the logcat as a bookmark or a 'marker' and scroll up/down to reference something else, but as the rows are reused the browser looses the selection
- current search is quite fiddly to me: filter by tag requires exact tag name, and 'search logs' searches only in 'message' field. also 'search logs' filters non-matching messages, I think both filtering/highlighting modes should be present, e.g. in Android Studio log viewer you could do both
- I often use standard in-browser search for the logs as it will search among all fields like process/tag/message and it won't filter out unmatches rows (just highlights the occurrences), but as only a subset of logs is actually rendered as DOM elements it doesn't work well
I would expect that some of the issues above could be solved by introducing a wrapped mode that e.g. will render out the whole log as DOM elements
cc @nicomazz
Okay, I think I'll take back 'even if it will hurt performance' 😅
I have tried to add multiline rendering by showing all items at once, and it makes zooming/panning the timeline uncomfortably slow... But it makes the logcat viewer much more useful
Would it be too difficult to make virtual scrolling with dynamic height?
Thank you, Steve! I have tried double clicking on the resize handle, it expands the column but it seems it is still limited to the screen width (or some other limit?).
There's an arbitrary limit of 2000px that I initially put on the cell auto sizer to stop columns becoming too wide, but TBH I think that was a mistake, I'll remove it.
The other thing to note is that the auto-sizer only works with the cells that are currently rendered to the DOM, because we can only measure what the browser has already laid out for us. This consists of the rows in the viewport +- a little skirt of a handful of rows above and below - unfortunately we do try to keep the number of DOM elements as small as possible for performance reasons!
I'm not sure if track name-like popup would work well as it's not copiable, maybe showing a persistent selectable multiline popup when double-clicking on a cell might work better?
I've got a shoddy demo working with this - it's very rough but I'll upload it with a link if you wanted to have a go.
I have tried to add multiline rendering by showing all items at once, and it makes zooming/panning the timeline uncomfortably slow... But it makes the logcat viewer much more useful
If you've disabled (removed) the virtualization option in logs_panel.ts, then I think there is actually a slightly confounding performance bug that I need to fix, but the vast majority of of grids in the UI use virtualization so I haven't prioritized it. Nevertheless, it doesn't scale to 10,000s or 100,000s of rows.
Would it be too difficult to make virtual scrolling with dynamic height?
Its tricky. You need to know all the heights up front, which means rendering all rows to the DOM at least once, which for 2000 rows might be fine but for 10,000 or 100,000 rows starts to become troublesome. I guess we could lazily load as we go so row heights are calculated as we reveal them which would work when scrolling slowly, but it doesn't work if you use the scrollbar to jump to the end for example. In short, I don't know, but we'd need to be clever about it.
An alternative is render only 50-100 rows at a time and use pagination, but I always find this to be an awkward UX because you have to scroll > change page > scroll > change page > etc ...
I find that often log messages are quite long and I would like to see/copy part of them common use case for this is stacktraces: currently it's almost impossible to read them as they are quite long and multiline
I feel like a persistent selectable multiline popup would resolve this problem.
I often select text in some line of the logcat as a bookmark or a 'marker' and scroll up/down to reference something else, but as the rows are reused the browser looses the selection
We could add a bookmark feature?
current search is quite fiddly to me: filter by tag requires exact tag name
Someone started a PR for this but it's stalled: https://github.com/google/perfetto/pull/3185
and 'search logs' searches only in 'message' field. also 'search logs' filters non-matching messages, I think both filtering/highlighting modes should be present, e.g. in Android Studio log viewer you could do both
This button toggles between filter / search, though the search is bad and doesn't let you jump through the items, it only hightlights them. We should fix this.
I often use standard in-browser search for the logs as it will search among all fields like process/tag/message and it won't filter out unmatches rows (just highlights the occurrences), but as only a subset of logs is actually rendered as DOM elements it doesn't work well
As above - we should just make search better!
Happy to review PRs if you fancied looking into any of these.
If you've disabled (removed) the virtualization option in logs_panel.ts, then I think there is actually a slightly confounding performance bug that I need to fix, but the vast majority of of grids in the UI use virtualization so I haven't prioritized it. Nevertheless, it doesn't scale to 10,000s or 100,000s of rows.
Yeah, I disabled this option, attaching my patch for history & if anyone else wants to try https://gist.github.com/lukaville/e69918917102f40eae772e6c4c00910b
(I also added an option to remove the time span filtering as it was also one of my pet pieves when analyzing logcat)
I've got a shoddy demo working with this - it's very rough but I'll upload it with a link if you wanted to have a go.
Sure, happy to try it out!
I think this could be a great middle ground if multiline rendering is not feasible, but I do still think that we should be able to see the whole message by default if possible, e.g. in case of stacktraces you might not have enough information visible in the first line to distinguish different items, so you would need to click through them.
Btw I do like how our internal android bugtool shows logcat and how it allows to filter the lines, I'm guessing it just operates on text lines level. Maybe we could add some pre-processing of the log messages to create synthetic log entries in case of multiline messages? also we could probably wrap and create extra log entries in case if the message is too long as well.
This way we would still be able to do the virtual scrolling, but seems like then copying won't work well (e.g. can't copy just the stacktrace, without each line having the timestamps/log level/etc.).
This button toggles between filter / search, though the search is bad and doesn't let you jump through the items, it only hightlights them. We should fix this.
Ah, nice! didn't expect that this button would switch between these modes. Do you think it would make sense to use filter icon & text here?
I've uploaded https://github.com/google/perfetto/pull/3381 which fixes the slow performance when not virtualized and also makes the msg column wider initially. It's just some small incremental improvements.
(I also added an option to remove the time span filtering as it was also one of my pet pieves when analyzing logcat)
Good idea, if you wanted to isolate that change and upload a PR I'd be happy to review.
Sure, happy to try it out!
Will upload something shortly.
Btw I do like how our internal android bugtool shows logcat and how it allows to filter the lines, I'm guessing it just operates on text lines level. Maybe we could add some pre-processing of the log messages to create synthetic log entries in case of multiline messages? also we could probably wrap and create extra log entries in case if the message is too long as well.
I think the best thing would be to do virtual scrolling with variable row heights 'properly' - whatever that looks like!? I'm sure it's not beyond the wit of man but it might be difficult to do without rows and the scrollbar jittering around & also I worry about performance. Just need to give it a go an find out really, but unfortunately it's not a massively high priority for me so I'm not sure if or when I'll get to it.
Ah, nice! didn't expect that this button would switch between these modes. Do you think it would make sense to use filter icon & text here?
Yep the icon isn't great - happy to review a PR if you have a better suggestion!