Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify zIndex context behaviour and sorting #343

Open
wouterlucas opened this issue Jul 17, 2024 · 2 comments
Open

Modify zIndex context behaviour and sorting #343

wouterlucas opened this issue Jul 17, 2024 · 2 comments

Comments

@wouterlucas
Copy link
Contributor

Currently a zIndex is required and every parent/child has its own zIndex context. This has an impact on performance because a) sorting is always performed and b) this triggers a lot of parent/child updates that bubble creating more re-sorts.

With L2 not providing a zIndex would not created a sorted zIndex context, similar to CSS. Alternatively you could set forceZIndexContext to true to force it.

Suggestion is to:

  • When no zIndex is provided do not create a zIndex context, see if we can skip the sorting for that node. Just like L2
  • Create an explicit do not sort flag or autosort=false flag, so the app framework can turn off sorting all together including parent/child event bubbling
  • Expose a .sort() function on the node to manually trigger a sort once

Alternatively we can also strip out the zIndexing all together and have the app framework take care of providing children in the correct order. However this would be a big behavioral change over todays implementation, however it would severely reduce the amount of sorting/bubbling the renderer needs to do every time.

Feedback please: @erikhaandrikman @elsassph @michielvandergeest

@elsassph
Copy link
Contributor

elsassph commented Jul 17, 2024

My opinion is that z-index should not reorder children, because currently it prevents a framework to control the nodes ordering (and BTW node children order should be directly controllable by the framework).

I believe the ordering should done at the rendering phase: when the quads are collected, they can be bucketed by z-index, then rendered in order.

Likewise, when you'll look at resolving elements at (x,y) it can return results ordered by z-index.

@Drulokia Drulokia self-assigned this Jul 18, 2024
@wouterlucas
Copy link
Contributor Author

We actually had z-ordering at addQuads before, but that would mean it would run it every time even when nothing changed on the ordering which was had a pretty big impact on performance. Which is why we changed it to be done ahead of time and using the update graph.

Bucketing by z-index is pretty intrusive, might as well look into depth buffer usage at that point. Though would need some metrics on how well that is supported across devices.

For now have the ability to skip sorting and providing presorted list on the API would be a good middle ground.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants