- From: Hendrik Mans <notifications@github.com>
- Date: Sun, 07 Feb 2021 07:57:00 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/565/774698029@github.com>
> Why did you remove it and went for the setAttribute hack? For context, it is important to understand that three-elements is, at its core, a game engine. Not a terribly good one, but it does the typical things a game engine does: provide structure, a solid ticker, and have a focus on performance. In games, doing everything within 16.7ms is critically important; in games _on the web_, where you're often dealing with lower-powered devices and/or want to conserve their batteries, even more so. MutationObserver was posing two problems for me: 1) It was _relatively_ expensive in terms of performance. When the project only has a couple of elements that get their attributes mutated on every frame, it wouldn't be a big problem (besides of using more CPU cycles than the alternative), but adding a higher number of elements -- maybe 50 and up -- to the scene quickly brought down FPS (by making individual ticks need more than said 16.7ms.) 2) Unless I'm mistaken, it performs its work asynchronously, which of course is totally understandable due to what it does and how it works, but it did create some confusing moments where some code updated another element's attribute, and the change wouldn't actually have registered until the next JS tick (not rAF tick), requiring me to go though `queueMicrotask` or `setTimeout` quite often. Not a terribly big problem, but it didn't particularly improve the developer experience. The first issue is of course much more critical than the second. Applying the `setAttribute` hack improved performance from "you can't build a simple Match-3 game with 60 FPS" to "you can barely find the attribute assignments in the profiler's flame chart", which is a _good_ optimization in the context of what I'm doing here. Last but not least, I should add that mutating my elements' attributes isn't even the _recommended_ way to work with the library; I typically advise users of my library to interact with the underlying Three.js object instances directly where possible, much like the react-three-fiber team advises their users to prevent React re-renders, but not only do I think it's great that you _can_ also set attributes without incurring a significant performance cost; ironically it is me who is using three-elements in a way where I _have_ to change elements' attributes and _can't_ work with the wrapped objects directly (I'm working with an experimental stack that involves server-sent and -diffed HTML.) I hope all of this sort of makes sense. Please let me know if you have questions, and even more so please let me know if you believe I had simply been using MutationObserver (or anything else, for that matter) incorrectly. Thanks! H. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/565#issuecomment-774698029
Received on Sunday, 7 February 2021 15:57:13 UTC