RFR: 6364: Improvements to the Thread Graph

[Alex Macdonald]

On Wed, 29 Apr 2020 10:23:24 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>>> I actually liked the old behaviour of being able to see all thread states on one screen (given that you had sufficient
>>> pixels to display them). It gave a more helpful overview of the application state during the recording. I.e. the old
>>> view had a minimum lane height of 1 pixel. To do the same thing here you'd have to collapse the table, since 1 pixel
>>> isn't enough to render thread names.
>> 
>> Fair enough, or perhaps allowing the chart lanes to shrink to that size, but have the text lanes remain at a size that
>> is readable? e.g., having the text lanes hit a min height of ~13px, so there will only be a difference in lane height
>> for 1-12px, and everything above that they re-sync in terms of height?
>>> The selection highlighter also seems to have taken a significant performance hit, so it's a bit harder to drag and
>>> select a region of threads.
>>> Unless I'm missing something it also appears that I can't sort the thread table, and I'm uncertain what order the
>>> threads are shown in now.
>> 
>> It should be the same order as they are now, the current table has been moved to be like a modal instead, it's
>> available to open via a button near the "edit thread activity lanes" button in the top-right of the page. It's the same
>> table, so the existing sorting mechanics should apply.
>>> I'm also a bit confused by why the scroll bar on the right hand side scrolls horizontally when it's rendered
>>> vertically,
>> 
>> Are you referring to the SWT spinner? That handles zooming in/out of the chart, and the scrollbar to the right of the
>> chart (should) scroll vertically.
>>> and the component now doesn't zoom through time with the scroll wheel, like all other pages do?
>>  
>> This has to do more with what the expected behaviour should be on a page that has scrollable content. In the cases of
>> the other pages, the charts/graphs don't scroll vertically, so having JMC-specific defined controls with the
>> scrollwheel to zoom should be fine. However, in many other applications where pages have scrollable content (e.g.,
>> internet browsers, photoshop, music editing software, etc.) the scrollwheel is reserved for vertically navigating the
>> content.
>>> It would also be nice if the "Thread State Selection" toolbar button could do more of the "Edit Thread Activity Lanes"
>>> dialog, since they're doing very similar things?
>> 
>> I could take a look into that, the concern was that it's quite a bit of information/controls to fit into a dropdown of
>> limited space without having it overlap too much of the chart content.
>
> Hi @aptmac - could you update this PR, please? Thinking of taking a closer look at it during the jmc dev hangout
> tonight. :)

Hi @thegreystone, I rebased the branch yesterday to be on top of master, and included a new commit based on the
feedback that makes the dropdown lane filter act like the Edit Lanes Dialog (screenshot below). Does the outdated tag
automatically remove itself what some criteria is met?

Edit: I also see that the checks failed, it looks like there's something wrong with the builds at the moment, I've been
seeing similar errors on my travis builds as well

![2020-04-27-171139_1177x829_scrot](https://user-images.githubusercontent.com/10425301/80604806-301c1000-8a00-11ea-82ce-88e55cc5d744.png)

-------------

PR: https://git.openjdk.java.net/jmc/pull/27