Created attachment 118938 [details] Video showing flickers Since a few days ago, I get severe screen flickering with black bars when I start Krita 4.2.0 Next nightly build through primusrun (so that it uses the dedicted GPU on my laptop) - before that it worked fine. If I then turn off OpenGL accelerated canvas it disappears. If I use optirun instead, there is no flickering issue. There is also no flickering problem with primusrun in Krita 4.1.8, or any other application I tested. Looking through my installed packages, neither the Nvidia driver nor Bumblebee have been updated in this timeframe. I attached a short video that shows it. Seems to be more severe in a maximized window, but never goes away completely. Version: 4.2.0-pre-alpha (git c475ecb) Languages: en_US Hidpi: true Qt Version (compiled): 5.12.2 Version (loaded): 5.12.2 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.0.3-1-MANJARO Pretty Productname: Manjaro Linux Product Type: manjaro Product Version: unknown 20 Mar 2019 15:25:10 +0100: Closing. OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "GeForce GTX 860M/PCIe/SSE2" Version: "4.6.0 NVIDIA 418.43" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: false isQtPreferOpenGLES: false == log == Supported renderers: QFlags(0x2) Surface format preference list: * QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) QSurfaceFormat::OpenGL * QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) QSurfaceFormat::OpenGLES Probing format... QSurfaceFormat::DefaultColorSpace QSurfaceFormat::OpenGL Found format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) QSurfaceFormat::OpenGL
Is this still the case with the latest appimage?
Yes, unfortunately it still is (git f3858d1), with optirun as well as primusrun. The flickers only become apparent once a document is opened or created, and only when there is any movement on screen. No issues with 4.1.8. Another way of avoiding it is starting an X session on the Nvidia GPU directly. In the terminal I see these lines repeated only with primusrun or optirun: qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 8) qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 8) qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 8) qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
Thanks for testing. I'm beginning to suspect that this is Yet Another Qt 5.12. Bug... I've got a laptop with both nvidia and intel gpu myself, but I haven't got anything setup to use the nvidia gpu... I'll probably have to do that :-(
Hm... Another question: if you use the nightly stable build appimage (which uses Qt 5.12), do you see the same problem: https://binary-factory.kde.org/job/Krita_Stable_Appimage_Build/ ?
No, the stable appimage seems to be unaffected (4.1.8-9347112). It also doesn't produce those messages in the terminal.
Okay, then it's likely not a Qt 5.12 bug, but a regression due the HDR related refactoring. Thanks again for testing -- I tried to install bumblebee on my laptop, but it doesn't seem to work at all.
Seems like this topic is dead, but I just want to say that I also have this issue on manjaro, so I'd like to see this getting resolved. Unlike op, though, running krita with optirun doesn't solve it. Nor does trying other versions. I checked, like, five or six of them and screen the issue still occurs in every one of those
Good reminder, optirun doesn't bypass the issue anymore for me either since an update several months ago. My workaround is to start a separate X session with the nvidia-xrun script, in case I need the Nvidia GPU.
I haven't managed to setup a test system, so I haven't been able to investigate it. It's also not the most urgent bug we've currently got open, since there are workarounds, I'm sorry.
As an update, I changed to a PRIME config for GPU switching on this same hardware over a year ago, as that is now the much more officially supported and less hacky way to switch between GPUs. I set Krita to start with prime-run instead and I don't think there was ever any rendering issue since then. The system info output in Krita confirms it's actually using the Nvidia GPU.
So should we close this report? @Mihail can you confirm if @M 's new workaround/way of getting it to work (using prime-run) works for you as well?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!