As per Wolthera's request at comment #6 of https://bugs.kde.org/show_bug.cgi?id=340085 here is a separate bug report for the light green cursor. It's tough on the eyes sometimes like on a light grey background. Also for me it's always the same color. Like I commented in the other bug report maybe there should be an option to change the cursor's color in Krita settings. As a workaround currently I create a new layer above the background I'm working with filled with black and 30% opacity. This makes the light green cursor more comfortable to work with on light backgrounds. My system details are: Windows 7 SP1 32 bit system Intel Core Duo 2.26 GH 3GB Ram ATI Radeon GPU Reproducible: Always Steps to Reproduce: 1.Use the brush tool 2. 3.
Created attachment 99014 [details] What the cursor is supossed to look like. The thing is that the green cursor is supossed to be mixed in with an exclusion blending mode, like in the screenshot I attached. So there must be an openGL problem here. Did this also happen in 2.9.11?
Created attachment 99015 [details] Open GL Enabled This is what the cursor looks in Krita 3.0 Beta with OpenGL enabled
Created attachment 99016 [details] Open GL Disabled This is what the cursor looks like in Krita 3.0 Beta with OpenGL disabled
I just sent a couple of screenshots of what the cursor looks like in Krita 3.0 Beta. Also please note the garbled text on the upper left corner of the canvas in the screenshot with OpenGL enabled. Don't know what's that supposed to be it's unreadable and it changes all the time (some kind of coordinates?) No the brush cursor wasn't like that in 2.9.11
I suspect this code in kis_opengl_canvas2.cpp: // XXX: glLogicOp not in ES 2.0 -- it would be better to use another method. // It is defined in 3.1 core profile onward. glEnable(GL_COLOR_LOGIC_OP); if (ptr_glLogicOp) { ptr_glLogicOp(GL_XOR); }
1DrawingPerDay: what GPU do you have?
Git commit 7236d4457d5b345dacadc22936e00d1bfac507ae by Boudewijn Rempt. Committed on 25/05/2016 at 12:10. Pushed by rempt into branch 'master'. Add note about gllogicop Though I think that on AMD, it doesn't work even if it's defined, so We still need to figure out another way to draw the cursor. Related: bug 340085 M +2 -0 libs/ui/opengl/kis_opengl_canvas2.cpp http://commits.kde.org/krita/7236d4457d5b345dacadc22936e00d1bfac507ae
@Boudewijn Rempt ATI Mobility Radeon HD 3650 with the legacy AMD Catalyst driver.
Okay -- then it's pretty clear my hunch was right and that this is something AMD's drivers don't support :-( On Intel and Nvidia, it's much better.
*** Bug 345918 has been marked as a duplicate of this bug. ***
*** Bug 347620 has been marked as a duplicate of this bug. ***
I have this problem on Nvidia GPUs 780ti and 1080
You should also note your operating system and the exact driver version you're using.
Happens to me in stable 3.1.1. Operating System: Windows 10 Home, 64-bit DirectX version: 12.0 GPU processor: GeForce GTX 1080 Driver version: 376.33
Created attachment 103903 [details] Patch -- QOpenGLFunctions_3_0 instead of GLES2 + WGL I did some tests and it seems Linux is not affected by this bug. For Nvidia it seems to break with driver 375.63+. (tested 368.81 - 378.49) For AMD I couldn't find a driver it would run correctly. (tested 13.251, 15.200) For Intel, this is my main computer running linux and I would rather not mess with its configurations too much.. Unfortunately I don't have a mac so I couldn't do any testing for it. I suspect the bug to be driver related and tried to debug wglgetProcAddress or rather the ICD implementation DrvGetProcAddress (nvoglv64.dll) once I ruled out invalid context, the possibility of wglMakeCurrent grabbing the wrong context, init failure, ... It is rather strange that only glLogicOp and none of the sync functions seem to be affected. First I came to a different conclusion so some material I gathered as proof become worthless but for some trivia, here some disassembly (https://gist.github.com/Joefish/c300ebac0cb579334838927d8cad26ba) The patch uses QOpenGLFunctions_3_0 to obtain an object pointer to supported GL functions instead of GLES2 compatible QOpenGLFunction + extension loading. According to Steam, Krita needs "Modern (since 2009) graphics / Intel HD" so GL3.2 sounds like a reasonable target, even for macs (in my opinion). It would also give a clear support target (instead of GLES2 + extensions), make many checks obsolete and in this case also circumvent a bug by just getting an offset table to the desired function subset. I think to remember than QPainter depends on deprecated GL functions and that's why 3.2core can't be set by default but Nimmy's opengl branch he already uses GL3.2Core (Core probably for compatiblity with OSX) like commit dd32d5e421a4a357e268bd2dbb8b679b6ddd2699 So, according to KisOpenGL::setDefaultFormat 3.0 is fine and once the way is free for 3.2 we can bump it up.
Hi Joe, Please also put this diff on phabricator -- apart from wolthera and me, most Krita developers don't look for patches in bugzilla, because of the volume of traffic. Unfortunately, as you probably know if you hung around on irc yesterday, I won't have time to dig in this week and probably also not next week. Do try to ping Nimmy, though!
https://phabricator.kde.org/D4506
I don't think this is an AMD-specific issue. 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. 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). The issue exists at least as far back as 3.0.0 (just tested that on my work machine) - I've never used any earlier versions and I can't find any setups for them, so I can't say anything about those.