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.

Sign up for GitHub

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

Jump to bottom

pick.py **PickBoundary** test has a lot of diffs with VTK 9.4 #20245

Open
biagas opened this issue Feb 19, 2025 · 0 comments
Open

pick.py **PickBoundary** test has a lot of diffs with VTK 9.4 #20245

biagas opened this issue Feb 19, 2025 · 0 comments
Assignees
@biagas
Labels
impact low Productivity trivially degraded (easily mitigated bug) or improved (enhancment) likelihood low Occurrence/expected use specific to data, operators, configuration, etc. or combinations thereof wrong results Causes non-obvious misinterpretation of data by users
Milestone
3.5.0

Comments

@biagas
Copy link
Contributor

biagas commented Feb 19, 2025 •
edited
Loading

I believe this is caused by the simulated mouse-pick (using screen coordinates). I think these should probably be removed as it is getting more difficult to get the screen coordinates that would work. Besides which, the way the test was originally designed, the results of the screen-pick were supposed to exactly match the PickByNode/PickByZone calls that immediately follow, but those results diverged a very long time ago.
@biagas biagas changed the title pick.py **PickBoundary** test has a lot of diffs. I believe this is caused by the simulated mouse-pick (using screen coordinates). I think these should probably be removed as it is getting more difficult to get the screen coordinates that would work. Besides which, the way the test was originally designed, the results of the screen-pick were supposed to exactly match the PickByNode/PickByZone calls that immediately follow, but those results diverged a very long time ago. pick.py **PickBoundary** test has a lot of diffs with VTK 9.4 Feb 19, 2025
@biagas biagas self-assigned this Feb 19, 2025
@biagas biagas added wrong results Causes non-obvious misinterpretation of data by users likelihood low Occurrence/expected use specific to data, operators, configuration, etc. or combinations thereof impact low Productivity trivially degraded (easily mitigated bug) or improved (enhancment) labels Feb 19, 2025
@biagas biagas added this to the 3.5.0 milestone Feb 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@biagas biagas

Labels
impact low Productivity trivially degraded (easily mitigated bug) or improved (enhancment) likelihood low Occurrence/expected use specific to data, operators, configuration, etc. or combinations thereof wrong results Causes non-obvious misinterpretation of data by users
Projects
None yet
Milestone
3.5.0
Development

No branches or pull requests
1 participant
@biagas