-
Notifications
You must be signed in to change notification settings - Fork 179
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.
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
Issue viewport navigation with lags #36
Issue viewport navigation with lags #36
Conversation
…intead of painting immediatly
…ndeled by the GLWidgetBase class
Ok, I like it. Common features of GLWidget and GLImage should be in one parent class. But I have one question: what should I call instead of updateGL() in GLImage? I'm asking because I checked your commit and with your source code version, the updateGL function does not work in GLImage class. I mean replotAllImages functions doesnt do what it shoud. |
actually, still |
updateGLNow() - solves the problem. You can test it with e.g. "Ctrl+R" after you translate UVs. |
…lags Ok, thanks for your contribution to AB project. Your code is perfect in comparison to my :)
Overview
Ok, this a quite a large Pull Request. The basic idea is, that there is now a helper class GLWidgetBase which is used as baseclass for
GLWidget
andGLImage
to allow integrating workarounds more easily.This pullrequests solves two issues on Linux:
Personally I don't like the code-style of my workarounds. So maybe you want to use the workaround only as inspiraton for your final fixes.
Not responsive Viewport
There's a bug in the propertiary NVidia driver. If your GPU is too powerfull and takes less than a milisecond to draw the image, it can happen, that the whole opengl window totally freezes.
Normally the solution is to limit the framerate. But as this is not a game with a main loop, this was not an option here. Especially, as the
updateGL
method is called quite ofter during one event queue execution, this would slow down the application extremly.Instead, my proposed solution is to override the
updateGL
method. It now doesn't paint the image immediatly, but instead queues the draw request exactly once, until the current event loop is done.The issue however was, that for some reason, the viewport needs to be rendered multiple times before all render-effects look correct. I have no idea why, so I added a workaround to activate the queue after the main event loop is started (indicated by the first mouse movement event).
Mouse lags back to origin
This is my probosed solution for issue #33
The problem here was, that the move events on linux are split into multiple small events. For example, if you are moving the mouse by 50 pixels into the right direction, you might end up with 50 events each with offset 1 pixel, instead of one events with 50 pixels at once.
My workaround is quite ugly. It accumulates the small events into one large event, which is more easy to handle. If my workaround is too ugly for your taste, simply ignore the commit f398fdd