> - Is the CSS parsing/loading offloaded to another thread? Or is there no > other meaningful "startup" work that could be done?
Usually, when JavaFX needs a Stylesheet, it needs it immediately. As you correctly imply, meaningfully offloading any parsing to another thread would require the caller to actually have significant alternative work left to do, as otherwise the caller would just be waiting anyway. > - Could CSS be loaded in parallel if it was split? That would be a major refactor of the CSS parser, and I don't think that there's any interest in that if it doesn't bring actual, tangible new features or significantly better maintainability that goes beyond a little bit of performance. > - Was there any low hanging fruit that could speed up parsing of regular > CSS files? Nothing comes to mind, but I'm sure that there are things we could do if we really wanted to. > - What are the challenges in maintaining the binary path? I would think > it shouldn't need any adjustment, but I fear that it probably does for > every new value type introduced... ideally these paths would converge > before types get involved. > > I'm certainly not attached to the binary code path; ideally, a binary > path should be low maintenance, and work more like a cache instead of a > different supported format. It is a bespoke serialization format that needs explicit support for every new feature added, most recently for media queries. In addition to that, JavaFX can read BSS files created with an earlier version of JavaFX (although this seems to be unspecified). I think we should be aware of the sunk cost fallacy. If we wouldn't want to create this binary serialization path for a few milliseconds of performance if it didn't exist today, then why would we want to commit to supporting it indefinitely just because it does? Is this _really_ a problem that needs solving, and is it worth to spend our limited resources on?
