Another viewport “problem”. I have used viewport.setScrollBarsShown(true, false, false, false); to prevent the horizontal scrollbar from showing and disable the horizontal scroll functionality overall. But I can still scroll horizontally using drag.
You need to disable scroll by drag separately using setScrollOnDragEnabled(false).
But I want to use scroll by drag. Just only in vertical direction and not horizontally.
Ah, gotcha. Misunderstood. Won’t that happen automatically if the component bounds in that dimension match the bounds of the viewport?
Well, yes.
In my case it’s just the vertical scrollbar that hides some content which causes horizontal scrolling. I can reduce the width of the viewedComponent but like in my other thread (Viewport, viewedComponent and position offset) this seems like an unnecessary hack.
Also for me this would include some other annoying changes. Since I have a centered component inside the viewport it would look a little off if I reduced the width. So I would have to define different offsets. It’s just easier disabling horizontal scroll.
Apart from that users would expect an argument called allowHorizontalScrollingWithoutScrollbar to disable scrolling when set to false.
its more the other way around. Viewport is using a hack to make scrollbar working and with it forcing any list that uses it to change its bounds instead and so also paint again all visible rows over and over again and so CPU load goes high.
When you disable the expected visibility with setScrollBarsShown(false,false,false,false) you pretty much end up with a Viewport that can only act on Keyboard input. Effective doesnt do what it tells. Even worse the slower you scroll the more CPU load you eat. So clearly a design flaw…
So this massive CPU load is not some curious CoreGraphic bug or so…
The problem is more that JUCE doesnt use coregraphics for real when you turn it on because the power of CG is its model and not its BackingLayer mechanics. uhh but thats not the question here…
So how does Scrolling work with apples native frameworks?
In the mac world there are two dedicated API for scrolling.
One is CAScrollLayer that just shifts its sublayers and does the clipping(masks), the other is the native scroll behaviour of NSView where one View is clipped by another…
Long story short, ending up with a complete re-develop of viewport and scrollbar handling for lists to lower CPU load when scrolling and make scrolling do what it says (just that).
Its the reason why i would opt to drop out of juce UI which is tedious to do…
At the moment i just lower development time because i have to hack juce do simple things right.
80 list entrys scrolling with juce ~45…110% CPU peaks for more then 1sec, memory + 25mb and back again, which tells there are a lot allocations happening.
80 list entrys scrolling with native API (NSView) ~1…2% CPU peaks for about 2secs, memory allocation balanced out of the cell factory. Its main thread anyway
80 list entrys scrolling with native API (CAScrollLayer) ~0,xy% CPU because the content is already there just the clipping changes.
1 Like