On Tue, 20 Oct 2026 16:56:03 GMT, Marius Hanl <[email protected]> wrote:
>>> I am not sure why the original developers decided that cells are precious >>> and need to be cached and reused. Maybe because the Node is heavy with all >>> these properties, I don't know. Perhaps, with gigabytes of RAM, we don't >>> even care. The cells should not be reused, much like popups and menus. >> >> The cell factory is user provided, and so cells may be arbitrarily heavy. >> For example, in my media application, a cell consists of about 20 sub nodes, >> including a few image nodes. Creating more of those than strictly needed is >> a waste. Not resetting them when not in use can hold on to an image (a video >> cover) that is potentially several MB's in size. I think FX not being >> aggressive enough with resetting/trimming is one of the reasons I wrote my >> own virtual container for this specific case. >> >> This is also basically what every other toolkit does, and for good reason. > >> I think FX not being aggressive enough with resetting/trimming is one of the >> reasons I wrote my own virtual container for this specific case. > > Thanks for the insights. This is actually another advantage of this PR: Cells > will now reset (call `updateItem` with `empty = true`) when not in the > viewport. > So I think this should actually fix your usecase (which I completely agree > on) too! > > This PR still needs a second reviewer, so if you like! > I do have a solution for this, that I use for my own programs. They're > basically a different kind of property that allows the owner of the property > (ie. the control, table, whatever) to control when listeners fire (something > we see already in some areas of FX where properties are "customized" to delay > firing, but that's usually manual and not coordinated across multiple > properties). I'm all ears. A solution to this problem in JavaFX would be great. Yeah JavaFX already uses this mechanism for e.g. `focusProperty` and it makes sense. > For example, if I need to change 3 properties, but they're all related (let's > say x,y,z) I can change all three, and only at the end of my changes have the > listeners fire. This is exactly what we need. > This is basically a general problem for any program that allows arbitrary > callbacks (which in JavaFX are often hidden in events/listeners). Calling any > callback while you're structure isn't in a fully consistent state is > problematic if your code must continue working no matter what silly things > the user might do there. > I think that's really one of the next areas (after correct old/new values > which was merged now) that JavaFX may see huge benefits from, especially for > insanely complex controls like TableView. I agree, and yes this will really be a huge benefit! It is also not just us who think this might need some improvements. I believe @mstr2 as well did write and drafted some improvements to the mailing list years ago as far as I can remember. > And even worse than that: a complete waste of time to fix, as you spend a ton > of code on these edge cases, code paths that are near impossible to exercise > and then almost never occur in the wild but still must be taken into account > just in case. Better to address the root cause, and then not only being able > to write the code much more directly, but also being able to proof that it is > correct in all cases as there no longer is user callback interference. > I like to think that current JavaFX properties in complex controls is like > writing a database program without having transactions. Sure, you may be able > to catch all possible problems and compensate for the lack of transactions, > but we're talking about a ton of code for situations that shouldn't even > occur in the first place. 100% agree. This is all visible in my current CSS 'saga' (bunch of PRs just to fix one flaw). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2347#discussion_r4327848104
