Hi John, That sounds very promising! Let me know when you have a PR available so I can test it out.
Quite sure I measured 10x, but maybe we measured something slightly different - or it's hardware-dependent. (The issue with scrolling happened only in my closed-source project, which has a behavior similar to ListVIew.) Florian Kirmaier On Mon, 1 Jan 2024 at 16:37, John Hendrikx <john.hendr...@gmail.com> wrote: > Hi, > > I think I've found the issue. Note that on my machine I can't really > reproduce the problem as clearly (Windows 10) as the performance > degradation is not quite as bad as mentioned in the issue (maybe a factor > of 2, and scrolling was unaffected), but it's probably what you are seeing > as little else changed in the PR that seems to be the root cause. Still, > VisualVM did hint at the probable culprit (SimpleSelector#applies). > > The problem is that BitSet (used for storing and comparing CSS style > classes) has special logic to do fast containsAll checks if it detects it > is compared against another BitSet. However, due to a read only wrapper on > one of the sets this detection fails, and it will fall back to standard > containsAll logic which is a bit slower. > > The fix should be relatively trivial, and I'll create a PR soon. > > I did note a few other things in my investigation: > > - JFXCentral has around 1000 style classes, which means a BitSet as > currently implemented, could use 125 bytes of memory for each StyleClassSet > if a high bit was set > - Most selectors involve only 1 style class, sometimes 2 and rarely 3 or > more > - Most nodes have 1 style class, sometimes 2 and rarely 3 or more > > Now, if I were to implement this kind of logic knowing that the number of > possible style classes can be quite high, and knowing that most selectors > and nodes will rarely have 3 or more style classes assigned to them, I'd > probably not use a non-sparse bit set as it is currently implemented. > > I've played around a bit with a sparse bitset, and although I did not see > amazing (overall) performance gains, the change (after applying the > regression fix) did shave off another 10-20 ms for the "loadTimeFX" > measurement in the JFXCentral application. > > --John > > > On 31/12/2023 15:24, Christopher Schnick wrote: > > Hello, > > I just tested this with our JavaFX application and can confirm that there > are massive differences. It takes around 1-2 seconds to completely apply > all application stylesheets in JavaFX 20 but takes around 6-7 seconds in > JavaFX 21. > On 12/31/2023 3:00 PM, Florian Kirmaier wrote: > > Hi Everyone, > > Sorry for the delay - but I couldn’t find the time to extract the > TestApplication for this bug. > Luckily, I found another application, which is also open source, which is > affected by the application. > > I'm speaking about https://www.jfx-central.com/ - both the desktop and > web versions are affected. > I’ve seen a performance deterioration of 10x when switching pages when > using JavaFX21 compared to JavaFX20. > > I’ve created a ticket with further instructions on how to test it: > https://bugs.openjdk.org/browse/JDK-8322795 > > Greetings > > Florian Kirmaier > > On Fri, 27 Oct 2023 at 21:31, Andy Goryachev <andy.goryac...@oracle.com> > wrote: > >> Please create a ticket, Florian. Would it be possible to profile the >> application when scrolling? >> >> >> >> Thank you >> >> -andy >> >> >> >> >> >> >> >> *From: *openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Florian >> Kirmaier <florian.kirma...@gmail.com> >> *Date: *Friday, October 27, 2023 at 04:20 >> *To: *openjfx-...@openjdk.java.net <openjfx-...@openjdk.java.net> >> *Subject: *Performance Regression in 21 - CSS >> >> Hi everyone, >> >> I've noticed that some parts of one of my applications is significantly >> slower with 21. It's fast with 20. >> The application heavily uses (and reuses) TextFlow with a Cell pattern. >> When I scroll, it is smooth with 20, but has big freezes with 21. >> >> I've tried all the commits that happened in between, and pin-pointed it >> down to the following: >> ticket: https://bugs.openjdk.org/browse/JDK-8304959 >> PR: https://github.com/openjdk/jfx/pull/1070 >> commit: >> https://github.com/openjdk/jfx21u/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1 >> >> >> According to the description and the discussion in the PR - this wasn't >> supposed to change any performance. >> Is this regression known? >> Otherwise, I should create a ticket for it. >> >> Greetings Florian >> >
