When using click and drag with the text tool (to set paragraph width), the vector layers ends up empty if the color is not dark enough. It happens since a few versions of the nightly builds (maybe since a few weeks). It doesn't happen when simply clicking on the layer with the text tool. Steps to reproduce: 1. Open or create a document. 2. Set the active color to a light value. 3. Select the text tool 4. Click and drag to create a paragraph with specific width. The vector layer created by the text tool will be empty, while in fact it should contain the paragraph (at the right width) with "Placeholder text" as text content. And if you create a paragraph with dark text this way (by click and drag), it will work, but if you want to change the color of the text to a lighter value afterwards, the program will hang (not necessarily crash). If I try to create a paragraph with light color, resulting in an empty layer, but I immediately try to change the color to a darker tone, I get this error popup: "Krita has encountered an internal error: SAFE ASSERT (krita): "!m_sanityIsStarting" in file C:/builds/graphics/krita/libs/global/kis_signal_compressor.cpp, line 210 Please report a bug to developers! Press Ignore to try to continue. Press Abort to see developers information (all unsaved data will be lost)" For color selection i use the triangle Advanced Color Selector in HSV mode. Any color picked in the top part of the triangle will be OK If I stick to the extreme bottom side of the triangle (really on the border, from pure white to pure saturation), it works too. But all the rest of the color selector surface will generate the bug. Krita Version: 5.3.0-prealpha (git e528a61) Installation type: portable package Hidpi: true Qt Version (compiled): 5.15.7 Version (loaded): 5.15.7 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.26100 Pretty Productname: Windows 10 Version 2009 Product Type: windows Product Version: 10 Result of IsWindows10OrGreater(): No
Hi, I can't reproduce this. Can you give me more information? 1. Which colors cause this? I have personally tried with "#99efe5", "#f4dad0" and "#d7d7d7", none of them seem to cause a crash. 2. Which font are you trying this with? Does it happen with all fonts?
I tried the colors you mentioned (#99efe5, #f4dad0, #d7d7d7) and it caused the same issue. I just noticed it doesn't affect all color hues in the same manner on my side either. For example for greens, the "zone" on the color selector creating the bug is fairly smaller, but still it's there. But shades of red are especially affected on my side. For example this one: #bf3429. The font is Segoe UI (default on Windows I think). I switch to Verdana and it doesn't change a thing. I'll try a total reset of my settings by moving temporarily my resources folder to see if it helps.
Update: I reset both my resources folder and the settings via the interface (Settings -> reset all settings) and the issue is still here for me.
So far I had the issue on two Windows computers (one on Windows 11 Home, the other on Windows 11 Pro). A total reset of Krita didn't help. I tested the same build on my Linux install (Mint Cinnamon), and no problem here. So it might be a Windows related issue. Tomorrow, I'll try to get my hand on the last nightly that didn't have the problem on Windows, if that can help find out what changed when it started to happen.
🐛🧹 Thanks for your comment! Automatically switching the status to REPORTED so the team can perform further triage. In the future you may also do this yourself when providing needed information.
Hi, I managed to test the nightly build on another Windows 11 computer (version 24H2) where there was no version of Krita installed before, and with only default settings. It seemed to work better, I could create text by click and drag with most of the colors that caused issues on my computer. But still, I could reproduce the bug with some colors, one of them being this one: #8fdf9b I created a block by click and drag with this color and the block appeared empty. If I create a block the same way but with another color that works, and then select the text and change the color to #8fdf9b, the text disappears, or worse, Krita hangs and crashes after a few seconds or minutes. I hope this helps reproduce the issue!
*** Bug 514390 has been marked as a duplicate of this bug. ***
Will add this note here in case it's easier to look here than go back to my report, on what I noticed when I experienced the bug. If the CYMK view is open in the specific color selector, it seems to be any color where the amount of black is 134 or less.
Ok, after asking around, this bug also happens on MacOS, Windows and Android... but not Linux; the platform I'm on :/ I'll mark it as confirmed for now.
So, we may have just found a fix for this: initializing the font metrics integers correctly. Freya was kind enough to help me debug this, and found that the font was offset massively off canvas, due the metrics being wrong. My suspicion is that what happened was that when we got our font metrics struct, because the values were not be initialized, they were reading the memory that was previously used by the font color and thus the font color affected the baseline offset and seemed like it would "dissapear" (it would be off-canvas). We're now initializing the font metrics properly, so this should be fixed. Please check if the next nightly fixes this!
Hi, Thanks a lot for looking into this, and for the fix :) I can confirm that now it works on Windows at least, with last night's build. I just wonder about the current behavior: when creating the placeholder text, the text color defaults to black no matter the color that is set as foreground color. So if you try to edit the text that sets the foreground color back to black. Would it be possible to have the color at text creation follow the current foreground color? With the current behavior, that means that if you set your color on the selector just before you create your text, you will have to set your color again manually after selecting the text (as you may not have that color in your color history yet).
Great, I'll close this then. > I just wonder about the current behavior: when creating the placeholder text, the text color defaults to black no matter the color that is set as foreground color. Yeah, that's a separate bug, still need to look into that.
The text-color-is-always-black is now also fixed, btw.
That's awesome, thanks a lot :)
Thanks so much for the fix!