When using a selection tool, the outline that is drawn before the selection is closed and turns into marching ants appears black instead of the usual green when OpenGL is turned on. This makes it difficult or impossible to see the selection as it is being drawn onto a dark image. Surface Pro 4 i5 8GB, Windows 10, Krita 3.0 (git f0cbffc) Reproducible: Always
Correction, it appears black instead of *inverse* on the SP4, and green instead of inverse on my desktop PC (which makes it hard to seen on green backgrounds).
Sounds very similar to this: https://bugs.kde.org/show_bug.cgi?id=363124 Does it sound familiar?
Surface devices are Intel, though. I can check later tonight. On my nvidia desktop selections were fine last night.
Actually now that you mention it the brush preview outline is indeed also affected. On the Surface it's black, on the desktop (which uses an NVidia GPU) it's green. So this does look to be related, and not just on AMD cards.
Hm, I'm puzzled. It's not screenshottable, but here on my sp3, the marching ants march, and over a dark background they are inverted -- while dragging the line is solid, and shows green over a dark background, when the selection is made, the ants start to march. What I see isn't different from 2.9 -- which sort of doesn't surprise me because that code didn't change.
Created attachment 99335 [details] Selections and outlines on SP4 and desktop in 2.9 and 3.0 Here's a screenshot comparison. I found the line tool preview is also black on the Surface and green on the desktop, no doubt other tools are affected as well.
I also have this issue Windows 10 x64, GeForce 680 GTX, last driver version (376.09) Here is a ScreenShot : https://monosnap.com/file/qpyTEeL7HtcmqpGfvw2UH4PkUz43qt.png
I can also confirm that cursor color is inverted (based on pixel under it) if I deactivate OpenGL.
At least with 3.1.2, I cannot reproduce this on any of my windows devices, including a surface pro 3 with Intel graphics, a desktop and mobilestudio pro with nvidia quadro. Like the cursor issue, which was worked around recently, I'm pretty sure that this is a driver bug :-(
I have this as well. Win7, GTX1070 driver 376.19. This was fixed here https://bugs.kde.org/show_bug.cgi?id=363124 and the cursor worked properly in the nightly I downloaded on march 14th. Now its broken again. Pressure sensitivity kept bugging out in that build so I couldn't use it past testing the cursor. Have been so far unable to use the 3.x branch
Created attachment 105508 [details] Screenshots of the brush outline at different locations The brush outline is all black here on release 3.1.3 for Windows x64. It's difficult to see the brush outline when painting on a darker area. Setup: - Windows 8.1 64 - Intel HD Graphics 4600 - NVIDIA GeForce GTX 960M
The selection outline seems to be fine for me (inverted), but the cursor is always green on every Windows PC I've ever used Krita on, all of which have various NVIDIA GPUs. This has been the case for as long as I can remember, with every GeForce driver version I've had for at least a year or so. (it's possible it may have worked correctly in 3.0 or some early 3.0.x version, but I can't confirm that at this point) The GPUs are if I recall correctly a GeForce GTX670 (my home gaming machine), a GTX660M (my old gaming laptop), a GTX1070 (my new gaming laptop) and a GTX960 (my work machine).
Out of curiousity, I downloaded an old Krita 3.0 setup and installed it on my work machine (GTX960), and it too has the always-green cursor. So it's been like that on every 3.x version at least. I've never used any version of Krita before 3.0, and there doesn't seem to be downloadable setups for them, so I can't say anything about those.
Various older versions of Krita are here: https://files.kde.org/krita/windows/
Are they gonna keep pointing fingers at video card manufacturers when it works flawlessly in 2.9 right now and always has. I've heard some total farce like "well new drivers don't support the old way so we changed it" and yet 2.9 still works like a charm on a brand new GTX 1070. This little bit of cursor code is obviously just broken and should be reverted back to what worked great for everyone. Someone actually fixed it recently in a nihtly and then it was re-broken in a short time??
Well, comparing the code between 3.x and pre-3.x, the more suspicious change is that a "brush outline workaround" thing now only activates if you DON'T use OpenGL. If someone can disable OpenGL in your Krita settings and test it, they will see if this alternate way of drawing the brush outline works -- and if it works then the problem might be with the GL painting code. https://github.com/KDE/krita/blob/master/libs/ui/tool/kis_tool.cc#L564
Shaun, It's rather disrespectful to speak of people present in this conversation as "they". We're not "they", we're people with names and faces who you can address directly.
I just tested an old 2.9.10 build from files.kde.org on my home gaming machine, and I can confirm that it seems to work correctly in that one. The cursor appears black when over white background and greenish when over other colors.
Please check whether this is fixed for you on 3.2 beta 1: https://krita.org/en/item/krita-3-2-beta-1-released/
Hi Alvin, thank you for the notification. With krita-3.2.0-beta.1-x64 portable, on my system, the program behaves as expected. It's a clearly visible brush outline. It seems the fix was this, for curiosity: https://cgit.kde.org/krita.git/commit/libs/ui/opengl/kis_opengl_canvas2.cpp?h=v3.2.0-beta.1&id=d0a329fa4d83576d729baae5a0f65f5b7810f289
Closing as per user response
It seems to work ! Here in v3.1.4: http://i.imgur.com/lOGvpyu.gifv Here in v3.2 beta 1 (openGL active): http://i.imgur.com/wdkrDm0.gifv Thanks !
That said, compared to black, light green still seems to be the "default cursor color" :P On photoshop foreg, Cursor is white against black (http://i.imgur.com/tKklDN2.gifv) In Krita v3.2 beta 1 Windows 10 (open GL active) it is green. Is this the expected behavior ?
Git commit 754ab2536610d2c4a6f5c8220cd294904b13cb33 by Alvin Wong. Committed on 19/08/2017 at 09:19. Pushed by alvinwong into branch 'krita/3.2'. Attempt to restore OpenGL 2.1 support on non-OSX systems Partially reverts d0a329fa4d83576d729baae5a0f65f5b7810f289 (D4506) and reverts the effect of 96835a05b874abe85b95e1aff525faa4a91368a8. `KisOpenGLCanvas2` inheritting from a versioned `QOpenGLFunctions_x_x` isn't the best idea just to get `glLogicOp`, so I try to use an alternative method to get it. `glLogicOp` is supposed to be in OpenGL core functions since full desktop OpenGL 1.0, just never had been a function in OpenGL ES 2.0 or above, so it should be available even with `QOpenGLFunctions_1_0`. I used `QOpenGLFunctions_2_1` just because that's the minimum version we seem to supported before 3.2 release. Related: bug 383281 Differential Revision: https://phabricator.kde.org/D7405 M +3 -2 libs/ui/opengl/kis_opengl.cpp M +20 -0 libs/ui/opengl/kis_opengl_canvas2.cpp M +6 -3 libs/ui/opengl/kis_opengl_canvas2.h https://commits.kde.org/krita/754ab2536610d2c4a6f5c8220cd294904b13cb33
Git commit 6ddc51090990c7e270540d83f9e7a129132f4ccf by Alvin Wong. Committed on 19/08/2017 at 09:32. Pushed by alvinwong into branch 'master'. Attempt to restore OpenGL 2.1 support on non-OSX systems Partially reverts d0a329fa4d83576d729baae5a0f65f5b7810f289 (D4506) and reverts the effect of 96835a05b874abe85b95e1aff525faa4a91368a8. `KisOpenGLCanvas2` inheritting from a versioned `QOpenGLFunctions_x_x` isn't the best idea just to get `glLogicOp`, so I try to use an alternative method to get it. `glLogicOp` is supposed to be in OpenGL core functions since full desktop OpenGL 1.0, just never had been a function in OpenGL ES 2.0 or above, so it should be available even with `QOpenGLFunctions_1_0`. I used `QOpenGLFunctions_2_1` just because that's the minimum version we seem to supported before 3.2 release. Related: bug 383281 Differential Revision: https://phabricator.kde.org/D7405 M +3 -2 libs/ui/opengl/kis_opengl.cpp M +20 -0 libs/ui/opengl/kis_opengl_canvas2.cpp M +6 -3 libs/ui/opengl/kis_opengl_canvas2.h https://commits.kde.org/krita/6ddc51090990c7e270540d83f9e7a129132f4ccf