On 3/9/24 10:30 AM, Marius Hanl wrote:
However, I found this old email thread. Two answers which reflect what
we said:
https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010067.html
https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010094.html
Wow, good find! Thank you,
Regarding the comment that the design of JavaFX is vastly superior to
Swing.. I would argue against bluntly stating that (not criticizing who
said that).
There are obviously cons and pros to each approach. On the one side Swing
was much easier for developers to extend and to add functionality on
On Wed, 3 Jan 2024 18:33:29 GMT, Kevin Rushforth wrote:
>> The regression is caused by the `Collections.unmodifiableSet` wrapper not
>> being recognized by `BitSet`, and a fall back is done to a less optimized
>> version of `containsAll`.
>>
>> As this is a regression fix, I've kept the fix
On 08/03/2024 07:37, Robert Lichtenberger wrote:
One major pain point that we have at the moment is CSS performance, I
think (but did not investigate yet) that some kind of performance
regression happened somewhere between 17 and 21.
I think this was addressed already, see here:
On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote:
> This PR fixes the border glitch/gap as explained in both linked tickets.
>
> I noted that the `ScrollPane` control does not suffer from this problem,
> although the code is mostly the same as in `VirtualFlow`. The `ScrollPane`
> snaps the
The fix is very straightfoward. We request a recreation of all cells in the
`VirtualFlow` by calling `flow.recreateCells()` when the `tableRowFactory` was
changed.
Funny enough, this was done in the `TreeTableViewSkin` again, hence it did not
suffer from this bug. Removed as the table row
> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is
> broken when `sizeToScene()` was called before or after.
>
> The approach here is to ignore the `sizeToScene()` request when the `Stage`
> is maximized or set to fullscreen.
> Otherwise the Window Manager of the
Yes, John made some good points about how the Behaviour API could look like, which I also agree on.
CSS will get performance improvements with the changes made by John in JDK-8322964, but I would agree that there is more in the CSS code which should/could be optimized.
-- Marius
I also remember that but not sure where I got this from as well.
However, I found this old email thread. Two answers which reflect what we said:
https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010067.html
I second this.
By no means we should open up everything in the Skins.
Some things may makes sense, some of them probably do not and I also would rather advocate copying and adjusting it as needed for bigger changes.
-- Marius
Gesendet: Samstag, 09. März 2024 um 05:46 Uhr
Von: "John
On Thu, 8 Feb 2024 18:55:54 GMT, Marius Hanl wrote:
> `TreeTableRow` does not check the item with `isItemChanged(..)`, unlike all
> other implementations of the cell.
>
> This also means that the `TreeTableRow` always updates the item, although it
> should not, resulting in a performance loss
On Sat, 9 Mar 2024 12:35:22 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Remove commented code in BitSetTest
>> - Remove unnecessary addAll overrides
>
>
> Improves performance of selector matching in the CSS subsystem. This is done
> by using custom set implementation which are highly optimized for the most
> common cases where the number of selectors is small (most commonly 1 or 2).
> It also should be more memory efficient for medium sized
On Sat, 9 Mar 2024 06:48:25 GMT, John Hendrikx wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done
>> by using custom set implementation which are highly optimized for the most
>> common cases where the number of selectors is small (most commonly 1 or 2).
>>
On Fri, 8 Mar 2024 22:59:42 GMT, Andy Goryachev wrote:
> This is another, unrelated issue: If I specify a number instead of duration
> like `-fx-show-delay: 1;` we'll get an exception every time the tooltip is
> about to be shown.
This is because the CSS implementation thinks it is a PX value
On Sat, 9 Mar 2024 10:27:21 GMT, Marius Hanl wrote:
>> This PR fixes a long standing issue where the `Tooltip` will always wait one
>> second until it appears the very first time, even if the
>> `-fx-show-delay` was set to another value.
>>
>> The culprit is, that the `cssForced` flag is not
> This PR fixes a long standing issue where the `Tooltip` will always wait one
> second until it appears the very first time, even if the
> `-fx-show-delay` was set to another value.
>
> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside
> the `TooltipBehaviour`. So
On Sat, 9 Mar 2024 04:07:45 GMT, John Hendrikx wrote:
> Perhaps we should open an issue to solve this for all controls in one go? A
> solution that would prevent **any** `Node` from being displayed without CSS
> applied?
Yes, that sounds like a good idea. Checking the calls to `applyCss`, it
On Fri, 8 Mar 2024 22:36:19 GMT, Andy Goryachev wrote:
> What I see is the very first time the tooltip appears it's using the old
> show-delay value of 1000ms. Any subsequent attempts the new delay is in
> effect.
>
> Then, change back to 1000ms. Same thing happens: the first time the old
>
19 matches
Mail list logo
