[External] : Re: JDK-8199934: ScrollPaneSkin incorrectly lays out its scrollbars

Mon May 1 21:43:27 UTC 2023

One more thing, ScrollPane is also missing an often seen use case:

Transparent scrollbars, or scrollbars that fade out after use. For one 
of my own panes, I've tweaked ScrollPane to have transparent scroll bars 
which overlaps the content always (ie. the content is visible below the 
scroll bar).  I do this with a new ScrollBarSkin that just puts the bar 
at a negative offset so it overlaps the content.  IntelliJ does this for 
example, as well as Visual Studio Code (for horizontal bar at least).

I think it already do this for touch platforms (embedded), but doesn't 
offer it for other platforms.  Someone filed a ticket for this: 
https://bugs.openjdk.org/browse/JDK-8091365

--John

On 01/05/2023 23:21, John Hendrikx wrote:
>
> I think we need to be very careful in adjusting preferred size based 
> on scrollbar visibility.
>
> ScrollPane's are used to avoid putting pressure on the surrounding 
> layout.  It's preferred size will often be ignored in most layouts 
> because its preferred size is the size of its content, which is likely 
> too large too fit (otherwise why use a ScrollPane). When a 
> ScrollPane's bounds become smaller, it must be careful not to change 
> its minimum space requirements, as that would be counter to its purpose.
>
> However, even changing its preferred size when space is getting 
> tighter may affect layouts in a way you really want to avoid. 
> BorderPane is one of many layouts, and even though what we're seeing 
> may seem like a bug, changing this behavior may have consequences.  
> What if the ScrollPane is in a VBox with two elements set to 
> Priority.ALWAYS, one being the ScrollPane?  When space gets tighter, 
> changing the preferred size to allow for a scroll bar is going to make 
> the layout jump a bit, because it will take away a bit of extra space 
> from the other element with Priority.ALWAYS.  VBox uses the preferred 
> sizes of all children as a starting point, and shrinks them to be 
> smaller to fit -- changing the starting point (the preferred size) 
> suddenly to make room for a scroll bar is not going to be smooth.
>
> I suspect in a lot of layouts the values for viewport width/height 
> will be set, as using the content as its preferred size for a 
> ScrollPane seems like a bad choice to begin with.  In the VBox 
> example, the preferred size would be so large when there is a lot of 
> content that it would swallow most of the extra space from any other 
> nodes set to Priority.ALWAYS.  Two ScrollPane's above each other would 
> not be equal sized, as their preferred starting sizes would be based 
> on their contents... it would look weird without setting viewport size 
> hints.
>
> I could imagine that there could be a different scroll bar policy, one 
> where room is always reserved for scrollbars, but they still display 
> only when needed.  This way, the ScrollPane, if it can be displayed at 
> its preferred size, would have sufficient room for a horizontal 
> scrollbar, and when it's horizontal size gets squished, it can display 
> it without needing to adjust its minimum or preferred sizes. If there 
> isn't enough room, it would pretty much function as before, where the 
> scrollbar overlays content when it does need to be displayed -- that's 
> unavoidable.
>
> There's also a similar issue: https://bugs.openjdk.org/browse/JDK-8095135
>
> --John
>
> On 01/05/2023 22:18, Andy Goryachev wrote:
>>
>> I think your diagnosis is right though: sometimes the layout is not 
>> triggered when a property is changed,
>>
>> the recent bug like that is
>>
>> JDK-8307117 <https://bugs.openjdk.org/browse/JDK-8307117> TextArea: 
>> wrapText property ignored when changing font
>>
>> I wonder if some kind of a generic unit test could be developed to 
>> identify such cases.
>>
>> -andy
>>
>> *From: *Nir Lisker <nlisker at gmail.com>
>> *Date: *Monday, May 1, 2023 at 13:09
>> *To: *Andy Goryachev <andy.goryachev at oracle.com>
>> *Cc: *openjfx-dev <openjfx-dev at openjdk.org>
>> *Subject: *[External] : Re: JDK-8199934: ScrollPaneSkin incorrectly 
>> lays out its scrollbars
>>
>> If I knew what the fix was I would have. Right now I'm not sure 
>> anymore what the correct behavior should be even.
>>
>> On Mon, May 1, 2023 at 10:44 PM Andy Goryachev 
>> <andy.goryachev at oracle.com> wrote:
>>
>>     Nir, would you like to submit a pull request?
>>
>>     Thank you
>>
>>     -andy
>>
>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of
>>     Nir Lisker <nlisker at gmail.com>
>>     *Date: *Sunday, April 30, 2023 at 10:04
>>     *To: *openjfx-dev <openjfx-dev at openjdk.org>
>>     *Subject: *JDK-8199934: ScrollPaneSkin incorrectly lays out its
>>     scrollbars
>>
>>     Hi,
>>
>>     I took a quick jab at this issue [1]. Using the reproducer in the
>>     ticket, launch and resize the stage vertically so that the
>>     buttons at the bottom are only partially visible.
>>
>>     The current behavior is as follows:
>>
>>     When the scrollbar is not needed, toggling to the AS_NEEDED
>>     policy reallocates the scrollbar space for the buttons (they move
>>     up).
>>
>>     When the scrollbar is needed, toggling to the AS_NEEDED policy
>>     still reallocates space, and the scrollbar takes away space from
>>     the content node. This is wrong.
>>
>>     I modified the method 'computeHsbSizeHint' to
>>
>>     private double computeHsbSizeHint(ScrollPane sp) {
>>         return determineHorizontalSBVisible() ?
>>     hsb.prefHeight(ScrollBar.USE_COMPUTED_SIZE) : 0;
>>     }
>>
>>     Now the policy toggling behavior is correct both when the
>>     scrollbar is needed and when it's not - the space is reallocated
>>     not at the expense of the content. However, enlarging the stage
>>     horizontally while AS_NEEDED is selected does not reallocate the
>>     space (you need to toggle the policies). I'm guessing there's a
>>     missing call to layoutChildren during this resizing.
>>
>>     Does anyone have any input here?
>>
>>     Thanks,
>>
>>     Nir
>>
>>     [1] https://bugs.openjdk.org/browse/JDK-8199934
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230501/7ce37f93/attachment-0001.htm>