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

[Neil Galarneau]

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 & I do
extra work to manage the (sparse) set of Cells that are non-standard
heights.
I understand that not everyone has the needs for this kind of layout
policy!
If you make the layout machinery available
background:rgb(228,228,228);">From: jonathan.giles at oracle.com
To:"Richard Bair" 
Cc:"openjfx-dev at openjdk.java.net" 
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 [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 [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 [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 [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:
[2] http://sitemail.hostway.com/http:
[3] http://sitemail.hostway.com/http:
[4] http://sitemail.hostway.com/http: