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

[Jonathan Giles]

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 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, 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 (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 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