Feature/Qt6 - Fix dropperSampler not working correctly #700
Conversation
This file contains 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
Signed-off-by: Patrick Bergeron <[email protected]>
pbergeron-adsk
requested review from
bernie-laberge,
eloisebrosseau and
cedrik-fuoco-adsk
as code owners
| @@ -89,6 +89,7 @@ namespace Rv | |||
| NODE_DECLARATION(launchTLI, void); | |||
| NODE_DECLARATION(rvioSetup, void); | |||
| NODE_DECLARATION(javascriptMuExport, void); | |||
| NODE_DECLARATION(framebufferPixelValue, Mu::Vector4f); | |||
There was a problem hiding this comment.
Please add this new command to the following file so that this new command is also available in python:
OpenRV/src/lib/app/py_rvui/rv_commands_setup.py
| void GLView::swapBuffersNoSync() | ||
| { | ||
| glFlush(); | ||
| glBindFramebuffer(GL_FRAMEBUFFER, 0); | ||
| glBindFramebuffer(GL_FRAMEBUFFER, | ||
| context()->defaultFramebufferObject()); |
There was a problem hiding this comment.
Good catch ! Thanks!
bernie-laberge
approved these changes
Feb 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summarize your change.
The dropperSampler tool in RV was not working correctly anymore in the qt6 branch. It had a strange offset (horizontally and vertically) because the OpenGL function glReadPixels was reading from the wrong context and the wrong framebuffer object.
in annotate_mode.mu, the method dropperSampler() called an OpenGL method (glReadPixels) while not in a rendering pass. This somehow worked in the old Qt5/GLWidget implementation, because the current OpenGL context and FBO always remained set to the main view widget. But since switching to Qt6/QOpenGLWidget, this no longer holds true - the Qt6/QOpenGLWidget backend has a OpenGL compositor that works differently, and the OpenGL context/fbo of the main view was no longer current after the application was done refreshing.
Since we want to query the final rendered view using glReadPixels, we implemented a mu method called framebufferPixelValue(x, y) which internally eventually sets the OpenGL context/fbo to the correct one, calls glReadPixels(), and then restores the old one.
Describe the reason for the change.
See first paragraph of the "Summarize your change" section
Describe what you have tested and on which operating system.
I have tested the dropperSampler tool, with different layouts and docked windows, but on Linux64 only. Please test in Darwin and Windows.
Add a list of changes, and note any that might need special attention during the review.
Please test and review on all other platforms please; although I am confident this will work just fine. During investigating this bug, the easiest way to see this problem was to dock the annotation bar on the left portion of the application window, thus pushing the main image window a bit to the right. Then, you'd easily notice that the color was wrong when you picked a color, which was horizontally offset by the width of the docked panel.
The easiest way to test and repro this, and to notice the fix works, is to start TV with the "smptebars.movieproc" argument, where you can clearly see the differences in color.
If possible, provide screenshots.
n/a