API to expose viewer limits to users #4844
Labels
enhancement
New feature or request
🪵 Log & send APIs
Affects the user-facing API for all languages
user-request
This is a pressing issue for one of our users
Milestone
Comments
jleibs
added
enhancement
|
Thank you for adding this! |
7 tasks
Wumpf
added a commit
that referenced
this issue
Feb 19, 2024
### What * follow-up of #5192 * Fixes #3076 * Fixes #4844 * _technically_ there's still limits (see #5192 ) but they are machine dependent making this relatively hard to query. Overall I'd argue we removed the previous limits so there's no need for this in the original sense. <img width="1252" alt="image" src="https://github.com/rerun-io/rerun/assets/1220815/512be197-9817-4f5a-8054-e3661346d361"> (note that we haven't spend a lot of time optimizing the collection of lines, large amounts of lines don't perform all that well so far) Applies the same principles as on the previous PR that fixes the point cloud limits. The key difference here is that we use lines in *a lot* of places, making this a bigger refactor than originally assumed. --- ~The need to know both strip & vertex count for lines ahead of time is a bit problematic and isn't always as easy as it was with points. We err on the side of generating more draw data bundles, but to limit this (a single drawdata for a single line is extremely wasteful as we have to allocate a bunch of textures, buffers, bind groups, etc. etc.) I had to introduce `LineDrawableBuilderAllocator` which is a very simplistic Vec-like allocator (minus the increase in size) for `LineDrawableBuilder` (previously called `LineStripSeriesBuilder`). I'm not super happy with this construct overall, but it's the best I could come up with in the short-term and things seem to be fairly robust and at least not overly complicated.~ ~In the future it would be nice to reconcile `LineDrawableBuilderAllocator` and `LineDrawableBuilder` into a single construct, likely still with the limitations that the size of a batch (think named unit with a transform) needs to be known ahead of time, which is practically always the case!~ --- Second iteration: There's now `DataTextureSource` (ideas for better names?) which is essentially a thing where you can throw data in and get a data texture out! It handles all the copies and dynamic sizings for you. This makes everything awesome because now we can handle `reserve` call just as an optimization without requiring them and without being on a bad path if you don't! <3 ### Checklist * [x] I have read and agree to [Contributor Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and the [Code of Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md) * [x] I've included a screenshot or gif (if applicable) * [x] I have tested the web demo (if applicable): * Using newly built examples: [app.rerun.io](https://app.rerun.io/pr/5207/index.html) * Using examples from latest `main` build: [app.rerun.io](https://app.rerun.io/pr/5207/index.html?manifest_url=https://app.rerun.io/version/main/examples_manifest.json) * Using full set of examples from `nightly` build: [app.rerun.io](https://app.rerun.io/pr/5207/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json) * [x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG * [x] If applicable, add a new check to the [release checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)! * [x] Test misc examples on WebGL * [x] Test misc examples on WebGPU - [PR Build Summary](https://build.rerun.io/pr/5207) - [Docs preview](https://rerun.io/preview/012ab21d8acbf86f8d45bfdba3737f8ebe989784/docs) <!--DOCS-PREVIEW--> - [Examples preview](https://rerun.io/preview/012ab21d8acbf86f8d45bfdba3737f8ebe989784/examples) <!--EXAMPLES-PREVIEW--> - [Recent benchmark results](https://build.rerun.io/graphs/crates.html) - [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The rerun viewer has a few constants baked into it related to maximium batch sizes for point-clouds, lines, etc.
Users currently have no way to find out about these limits without logging and then seeing whether or not the viewer itself produces an error.
It would be nice if users could query these limits so that they can do their own client-side validation instead of just logging data that will fail to show up. Without an API contract for this users will end up baking in hard-coded limits that could become invalid or inappropriate in future releases.
The text was updated successfully, but these errors were encountered: