Ideas how to make a "StickyHeaderList" with a JList and or JTable

[bric3]

I saw this pattern used quite a lot in mobile apps, and I think this could really be interesting for desktop as well.

[aterai]

It looks like Sticky Header can be implemented in Swing by using JLayer. If possible, I would like to create a example in the next month or so.

[bric3]

Ah interesting! I didn't think about that, I was thinking about making something inspired by the materialized row of IntelliJ JListHoveredRowMaterialiser, but the JLayer might be a better approach here !

[aterai]

Before creating multiple sticky headers, we created an example of a simple single sticky header JList. #29
Please check and modify the operation when you have time.

[bric3]

Hi, thank you for looking into it !
Note I was mostly mentioning the single sticky header UI pattern. Not necessarily looking into the "multiple" one.

By the way, I noticed the scrolling speed is different between the two lists. The one with the Layer seems slower (using the macbook trackpad), I'm not yet sure why.

[bric3]

Profiling the code shows indeed more time spend in the StickyLayerUI.paint. Not sure yet what to optimize, the super.paint looks like the one taking much of the time. Also more time is spent delivering the mouse events with the sticky header list, but this could be a side effect 🤔.

with stick header

regular list scrolling

JFR profiles
2024-11-25T1302-StickyHeaderList-profiles.zip

[aterai]

Thanks for profiling the code😀.

the scrolling speed is different between the two lists

In the default JList on the left, the mouse wheel scrolls in cell blocks, but in the JList on the right, you can set JList#getVerticalScrollBar()#setUnitIncrement(2); to scroll in pixels to It is easier to see the sticky header replacement. The scroll amount of 2px seems to be too slow, so modified it to 4px in both JLists.

Profiling the code shows indeed more time spend in the StickyLayerUI.paint

Since there is no need to redraw when moving the mouse, have modified it to exclude this.

[bric3]

@aterai Ah, I missed the unit increment indeed! This clearly has an effect on scrolling speed.

I pushed a bit the curiosity and I experimented using various increment values, and discovered that the JDK's Aqua ScrollBar contributes ~7% of the samples for almost any value of the unit increment, and the other contribution is usually the list UI that takes around 4%.

And even without setting the unit increment (i.e. it's per cell blocks), the AquaScrollBarUI.paint takes a significant time 7% - 10%.

I wonder if this is something more visible on HiDPI screens.

For reference I'm running corretto-23.0.1.8.1 on macOs 15.1.1.

---

By the way I used IntelliJ Ultimate that integrates Async Profiler under the hood. And allows to visualize the JFR recording within IJ. I don't know if it's available on Windows though.