[Review Request] Support fixed cell heights in JavaFX UI controls

[Neil Galarneau]

Sorry for the mangled message.
The mangled end of my message was:
If you make the layout machinery available
padding:0px;color:rgb(51,51,51);line-height:19px;">
I assume doing this kind of layout requires coordination between
TableView's and TableRow's Skins.
Thank you for your consideration,
Neil 

----- Original Message -----
From: Neil Galarneau 
To:
Cc:
Sent:Mon, 20 May 2013 14:46:58 -0500
Subject:Re: [Review Request] Support fixed cell heights in JavaFX UI
controls

 Increasing the scalability of these controls would be excellent!

 Your proposal is for an alternative layout policy that is simple and
 would be very scalable.

 I also need a scalable TableView/TreeTableView, but I need more
 flexiblity in my layout policy. For example, it would be useful to
me
 to have a layout policy where most Cells are the same height ">From:
jonathan.giles at oracle.com [1]
 To:"Richard Bair" 
 Cc:"openjfx-dev at openjdk.java.net [2]" 
 Sent:Tue, 21 May 2013 07:18:53 +1200
 Subject:Re: [Review Request] Support fixed cell heights in JavaFX UI
 controls

 On 21/05/2013 3:45 a.m., Richard Bair wrote:
 >> In our ongoing effort to make JavaFX fast, especially on
 constrained systems such as the Raspberry Pi, I'd like to propose
the
 addition of API to the ListView, TreeView, TreeTableView and
TableView
 controls that allows for developers to specify a fixed row height
for
 all rows. Should a developer set this, they would be explicitly
 telling JavaFX that their cells will not dynamically resize.
 > Actually, it is more than this, isn't it? Beyond not dynamically
 resizing, it also means that the height of each row will not be
 determined by the CSS properties (padding, etc) specified on the
 cells, or the cell's preferred size, or the cell's content. So when
a
 developer sets the fixed row height, they would either do so via CSS
 (so they can use 'em' calculations to make the row height based on
the
 font) or they would have to determine the number for themselves in
 some other manner (including just making it up!). Is that right?
 Yes, this is right. In all my testing I've simply specified the
 fixed 
 height as 24 (which is approximately the size of cells by default).
 >
 >> In return for giving up this functionality, JavaFX can do two
 things that massively helps performance:
 >>
 >> 1) The virtualisation code can short-circuit all height
 measurements (and many resizing operations). This saves JavaFX from
 having to perform massive amounts of string measurement, which is a
 big bottleneck.
 >>
 >> 2) The TableView and TreeTableView controls can virtualise in the
 horizontal direction. In other words, for all columns that are not
 visible (as the width of all columns exceeds the width of the
 TableView itself), the cells contained within obstructed columns
will
 be removed from the scenegraph (and added back in as necessary as
the
 user scrolls horizontally). This saves JavaFX from having to perform
 CSS / layout on all of these cells. The reason why this is enabled
 only with fixed cell height is because we can not know whether cells
 outside the visible area have an impact on the row height.
 >>
 >> In our tests enabling a fixed row height has massive gains in
 runtime and startup performance. It won't be useful to everyone, but
I
 would imagine that it would be applicable for most people However,
 because enabling this by default would potentially break a lot of
 people, this functionality will _not_ be enabled by default.
 >>
 >> I'm slightly conscious of the fact that using the term 'fixed
 cell _height_' is confusing in the case of a ListView which is laid
 out horizontally. Therefore, my suggested API would be either a
 fixedCellHeight double property or a fixedCellLength double property
 (where length is the term used internally to differentiate from the
 cell breadth). From an ease-of-understanding point of view I much
 prefer fixedCellHeight however - most people won't be using
horizontal
 ListViews, so it is unlikely to be confusing. My preferred approach
 would be to have the property default to Region.USE_COMPUTED_SIZE
[3] [1]
 to indicate that fixed cell height should not be used. To enable the
 functionality, a positive value can be set. I'm not wed to using
Region.USE_COMPUTED_SIZE [4] [2], so if that feels confusing we could
just
 state a negative value will disable the value.
 > Probably I would go with the negative value since
Region.USE_COMPUTED_SIZE [5] [3] (although conveniently named) would
be
 used out of context (where the context is with min/pref/max
 widths/heights).
 >
 > fixedCellSize as suggested by Philipp seems nice.
 As I noted with Jasper, it seems like fixedCellSize is the current 
 leader, so I'll be going with that in my proposal. I'll also not use

Region.USE_COMPUTED_SIZE [6] [4] for the reasons you state - I also
felt
 a 
 little unhappy with it so I'm happy to just go without.

 If there is no further discussion I'll update the jira issue today
 with 
 the details and will update with the api-review label to get the +1
 from 
 you asap.

 -- Jonathan

 Links:
 ------
 [1] http://sitemail.hostway.com/http: [7]
 [2] http://sitemail.hostway.com/http: [8]
 [3] http://sitemail.hostway.com/http: [9]
 [4] http://sitemail.hostway.com/http: [10]



Links:
------
[1] mailto:jonathan.giles at oracle.com
[2] mailto:openjfx-dev at openjdk.java.net
[3] http://sitemail.hostway.com/http:
[4] http://sitemail.hostway.com/http:
[5] http://sitemail.hostway.com/http:
[6] http://sitemail.hostway.com/http:
[7] http://sitemail.hostway.com/http:
[8] http://sitemail.hostway.com/http:
[9] http://sitemail.hostway.com/http:
[10] http://sitemail.hostway.com/http: