On Thu, 9 Jan 2025 18:53:39 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
> This outcome is what I would expect, and it puts an upper limit on the number > of nodes that you can front-insert one by one into a container (the time > complexity grows quadratically, so you'll pretty soon freeze the application). > > Note that back-inserting, or bulk-inserting nodes should have no noticeable > performance impact. > > I think our options are the following: > > 1. Discard this feature. > 2. Accept that this particular way of adding nodes to a container has a > prohibitive time complexity for many nodes. > 3. Do something clever, for example only toggle the pseudo-classes once per > pulse. The disadvantage of this approach would be that the pseudo-classes of > a node may be wrong after it is added to a container, and would then later > fix themselves in the next pulse. > 4. Do something even more clever, for example only set the pseudo-classes > when someone is actually listening or retrieving their value. It may be possible to have these simply be synthetic (including first/only/last child). If the index of a child is known, and the size of its container, these can be trivially be computed on demand instead of fully materialized and made part of a list. I couldn't find how browsers generally do this, but I suspect it will be highly optimized. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2581289531
