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

Scott Palmer swpalmer at gmail.com
Mon May 20 16:14:54 PDT 2013 

Hopefully scrollbar calculations will be easier to manage with this.
 JavaFX 2.2 has a horrible time rendering a proper scroll control with
table rows that vary in height. (Thumb size is all over the place and the
scrolling jumps around like a drunk cricket)

I personally thought Region.USE_COMPUTED_SIZE was a perfect fit. Why make
it something different when it basically will mean the same thing?  But I
don't care so much, and it seems the vote has already gone in the other
direction.

Scott


On Mon, May 20, 2013 at 3:52 PM, Neil Galarneau <neil at galarneaus.net> wrote:

> 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:
>
>

More information about the openjfx-dev mailing list