[pure refactor] Picking configuration is now part of view builder setup#11082
Merged
[pure refactor] Picking configuration is now part of view builder setup#11082
Conversation
Contributor
|
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
Wumpf
commented
Sep 2, 2025
96008a1 to
e7e6bbe
Compare
1 task
Member
Author
just barely 😅 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, to set up picking on a
ViewBuilder, you'd callschedule_picking_rect. With this refactor, it's instead part of the views initial configuration. Surprisingly, that's practically no issue at all for our existing Viewer & example code 🤷Why the hassle though, what's wrong with the old way?
This is a small piece of prep work I split out of another renderer refactor/enhancement pet-project of mine. At the core the issue addressed here is that it's very useful to know what draw phases are active when enqueuing
DrawData. With theschedule_picking_rectapproach this information wasn't guaranteed to be available ahead of time.(With this, the only draw phase we don't know about whether it's active is the "screenshot phase" which is a bit of a strange copy-shim, rather dubious that it's a full phase in the first place.)