ecs: let a changes finalizer learn that components with a trait were written through a row
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 15/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- devtools
Hướng nghiên cứu
The request is a design change to the changes finalizer in the ECS layer, so start by locating how Finalizer.changes and its watch option are implemented and how row assignment (row[component] = value) is tracked versus command-based structural changes. Decide whether a per-table dirty bit or a changes.written field is the right shape, and agree the API with maintainers before writing code. Done means a finalizer watching a trait is notified when a row system writes one of its components, without scanning rows.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
A changes finalizer can't see a component's value being written through a row (row[component] = value in a row system), only structural changes (added, removed, spawned, despawned). So state that lives in a component and is moved by a row system (a camera's position and look, moved every frame by the control) can't be saved on change by a finalizer that watches a trait, and has to be polled.
Where this came from (mecs)
mecs keeps per-tab state (the camera's cameraPosition and cameraLook, plus resources like the selected tool) under a trait of the app's own (inTab). With 0.3.0 trait watches (#242) the resources are noticed by Finalizer.changes({ watch: [inTab] }), which is what I wanted. But the camera is a component of an entity and controlCamera moves it with row assignments:
System.create({ components: { with: [cameraPosition, cameraLook, ...] } }, row => {
row[cameraPosition] = next.position; // not reported to a changes finalizer
});
A finalizer watching inTab never fires for that. So the tab's state is polled four times a second (take a snapshot, encode it, compare bytes) which is correct but does the encode work 240 times a minute while nothing changes.
What I need
Some way for a finalizer (or a system) to learn that components with a trait were written this tick, by row or by command, without scanning every row:
- a
changes.written(or the existingchanges.groupscarryingreplacedfor row writes) per table for watched components; or - a
Finalizer.changesoption that also reports "this table's column was written", coarse is fine (a table-level dirty bit per watched column, set by row assignment, cleared when finalizers have run). I don't need which row or the values, only that something changed, because the consumer re-snapshots.
The changed: [component] filter of a system already has this information per row (it is how deriveCells runs only on moved voxels), so the world already tracks a version per column or row; this is asking for it to be reachable from a finalizer's watch, including by trait.
Why a coarse signal is enough
The consumer is "save the tab's state soon after it changes": a timer then a snapshot. A dirty flag per watched table, read once per tick, replaces the 4 Hz byte-comparing poll with nothing at all while idle.
- Ngôn ngữ chính
- TypeScript
- Star
- 12
- Fork
- 8
- Merge trung bình
- 11 giờ 2 phút
- Pull request đã merge (30 ngày)
- 23
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của adobe/data
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ecs: let kernels issue commands through helpers (component lists, symbol-keyed values, void helpers)Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ecs: an architecture standard (layout, naming, exports, checker, diagrams) for the new ECS samples, and how to distribute itCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 8/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
test: claim-conflict drop leaves both facts active and is never re-proposed (untested review cell)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Feature]: Usage page should show API-equivalent cost and say when a connected plan shows info onlyĐang mởenhancement from-x
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
nightly-labs/openbot#4867 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
egonSchiele/agency-lang#1377 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
normalizePath removes the Windows device namespace prefixCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
caprover/caprover-frontend#273 ·
Maintainer thường phản hồi trong vòng 1 ngày