[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #19 from Tyson Tan --- Thank you, Boud! :D -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 306182] Add Stroke Selection Edge function
https://bugs.kde.org/show_bug.cgi?id=306182 --- Comment #6 from Tyson Tan --- Thank you everybody! Can't wait! :D -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 370319] Flatten image crashes Krita
https://bugs.kde.org/show_bug.cgi?id=370319 --- Comment #3 from Tyson Tan --- Thank you, Boud! :D -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 342141] Export filters should warn if the image contains unsupported features.
https://bugs.kde.org/show_bug.cgi?id=342141 --- Comment #9 from Tyson Tan --- Thank you, Boud! Hope we can soon see this fix at work. Additonally, today I just received another question about wrong color output because people are using sRGB-elle-v2-srgbtrc.icc with 16 bit while exporting it as PNG. They do that all the time because we tell them 16 bit is superior. Can we just automatically convert the color space to sRGB 8bit for them while exporting as JPG/PNG? Or, do we consider collapsing those color space options by default in Document Creation dialogue? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 370319] Flatten image crashes Krita
https://bugs.kde.org/show_bug.cgi?id=370319 Tyson Tan changed: What|Removed |Added CC||tyson...@mail.com --- Comment #1 from Tyson Tan --- Same here using krita-3.0.1.90-x86_64.appimage -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369344] New: Confusing Zooming Icons in BrushesAndStuff toolbar
https://bugs.kde.org/show_bug.cgi?id=369344 Bug ID: 369344 Summary: Confusing Zooming Icons in BrushesAndStuff toolbar Product: krita Version: 3.0.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com The current renewed Zooming Icons in the BrushAndStuff toolbar are unconventional. They look cool but they don't link with people's concept of zooming very well. The Zoom In and Zoom Out icons are basically the same! The arrow pointing to a diagonal direction, VAGUE. To make the current concept work better, we should reverse the arrow direction of Zoom Out icon so it shows "big>small" But the best solution is still a magnifier with + and - in it. We have perfect built-in context that way, and do not need to resort to direction and other stuff to understand what they mean. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 369343] New: Multiple Usability issues of Color Palette Docker
https://bugs.kde.org/show_bug.cgi?id=369343 Bug ID: 369343 Summary: Multiple Usability issues of Color Palette Docker Product: krita Version: 3.0.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Dockers Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com The current UI of Krita's Color Palette Docker is very confusing: 1) It's called "Palette". It should be called "Color Palette" to provide context in the huge Docker menu, and to discriminate from Popup Palette. 2) It doesn't work when no palette is loaded. New user will never figure out why there are buttons there, they can click on it, but nothing happens! Therefore, it should always have an empty palette loaded BY DEFAULT, until the user changes it. 3) There is no indicator showing "No Color Palette Loaded" (disabled) state and no instruction in place to tell user what to do to enable it. When No palette is loaded, we should put instruction text into the empty docker, so the user may teach themselves. 4) In "Choose Palette" dialogue, we must "Input a new name and Save" to create a new palette -- this is unintuitive. Again new user will never figure that out. We have 2 empty space for buttons there, why not add a "New Palette" button and a "Rename" Button side the existing ones? What's more, why not use right-click interaction there? That's the perfect situation for a contextual right-click, I think. 5) Unintuitive icons. "Add Foreground color" should be an "Swap-FG/BG" icon; "Add Color" should be a Color Picker or +; Delete should be an "X" instead of a Stop sign. In fact, we are mixing DELETE with STOP SIGN everywhere in Krita, which very confusing. 6) We also need to add "Resize" buttons to the docker. Again new user will never figure out to use Ctrl + Wheel. At the end of the day, I think we depend too much on the user Googling for instruction. In most cases, people just think that function of Krita is broken and give it up -- just like I did -- today I finally figured it out for the first time, because I needed it so bad and refused to believe it is still broken for so many years. Yet it took me quite sometime to finally understand Krita's Manual page on that topic. The interaction design is just too obscure, like Enigma! XD Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 368849] [Windows] Krita does not react to Wacom Penabled tabletPC stylus's Top Barrel Button/2nd Switch mouse event on canvas
https://bugs.kde.org/show_bug.cgi?id=368849 --- Comment #2 from Tyson Tan --- Created attachment 101172 --> https://bugs.kde.org/attachment.cgi?id=101172&action=edit Krita under Windows 10 Cube i7 Stylus Top Barrel Button tablet log Hi, wolthera I don't know exactly what the tablet log was saying, but it seems Krita thinks the top barrel button belongs to a mouse and block its signal? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 368849] New: [Windows] Krita does not react to Wacom Penabled tabletPC stylus's Top Barrel Button/2nd Switch mouse event on canvas
https://bugs.kde.org/show_bug.cgi?id=368849 Bug ID: 368849 Summary: [Windows] Krita does not react to Wacom Penabled tabletPC stylus's Top Barrel Button/2nd Switch mouse event on canvas Product: krita Version: 3.0.1 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: tablet support Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com When using a Wacom Penabled TabletPC (Thinkpad X201T, X230T, Cube i7 Stylus) with a 2 button/switch stylus (UP-911E-02DD) under Windows 10, Krita does not react to the Top Barrel Button's mouse event on canvas. Reproducible: Always Steps to Reproduce: 1. Windows 10 X64 (not tested on other versions of Windows) 2. Krita 3.0.1 3. Wacom Penabled Tablet PC (like: Thinkpad X201T, X230T, Cube i7 Stylus) 4. Wacom Penabled compatible 2 barrel switch stylus (like: UP-911E-02DD) 5. Wacom Feel Driver installed, checked "Use 2 button Pen" and "Hover Click", Unchecked "Show ripple effect", set Top Barrel Button to Right Click, Bottom to Middle Click. (same as Ubuntu) Actual Results: Top Barrel Button (mapped as Right Click at the moment) cannot call up Krita's Popup Palette on canvas. In fact, no matter what mouse event you assigned to the Top Barrel Button, Krita does not react to them on the canvas. However, In Settings>Canvas Input Settings, Krita can read the signals sent by the Top Barrel Button. Meanwhile, Top Barrel Button Right click seems to be recognized by other apps on the same Windows 10 system. Expected Results: Krita react to the Top Barrel Button mouse event on its canvas. Workaround: 1. In Krita's Settings>Canvas Input Settings, change your target action into "Key combination". In this case, add a Key combination shortcut "Ctrl+P" to "Show Popup Palette". 2. In Wacom Feel Driver, map Ctrl+P to Top Barrel Button. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #27 from Tyson Tan --- Created attachment 100883 --> https://bugs.kde.org/attachment.cgi?id=100883&action=edit Kiki with sRGB chunk, Ubuntu default settings (CMS ON, auto profile), Firefox default settings -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #28 from Tyson Tan --- Created attachment 100884 --> https://bugs.kde.org/attachment.cgi?id=100884&action=edit Kiki with sRGB chunk, Ubuntu with calibrated profile, Firefox default settings -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #30 from Tyson Tan --- Thank you for the patch, wolthera! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #29 from Tyson Tan --- Created attachment 100885 --> https://bugs.kde.org/attachment.cgi?id=100885&action=edit Kiki with sRGB chunk, Ubuntu CMS OFF, Firefox default settings -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #25 from Tyson Tan --- Created attachment 100881 --> https://bugs.kde.org/attachment.cgi?id=100881&action=edit Windows driver with embeded ICM profile Some additional information: On Windows, I highly suspect we need to install a proper driver for the monitor in order to reproduce color difference. In this screenshot, the "Generic PNP Monitor" is actually a Cintiq 13HD. There is no ICM profile associated with this Windows default driver. If this is what your monitor looks like in Windows Device Manager, color management is most likely being turned off. That’s probably why you don't observe color difference in Firefox. Since Windows XP, Windows began to automatically pull drivers from Windows Update. Windows 10 has a very large online driver library that it can solve most driver problem by itself. That service brought about new problems -- I didn’t install NEC PA242W’s driver in that screenshot. Windows 10 did it. PA242W’s driver has an ICM profile. So far as I know, every specific monitor driver provided by the manufacturers has an ICM profile. All these ICM profiles share a similar characteristic: that funny blue response curve in TRC view that greatly deviates from the center. If you are running Thinkpad X/T/W/P laptops, Lenovo provides laptop screen drivers on their website (some only shown when you select Windows 7). When I was using Thinkpad X201T/X230T, I once installed the monitor driver and the color shift happened right after that. Same thing happened for all my DELL monitors and even a cheap crap like Philips 190EL...yeah they even bothered to provide a driver. Probably an industrial standard or something. I never encountered this problem soon after I migrated to Linux and started color managing my monitors. That’s why I have completely forgotten this problem until it surfaced again when I was using my totally unmaintained Windows 10 to test Krita there. My suggestion on environment to reproduce this problem: On GNU/Linux: Ubuntu Original / Ubuntu Gnome. Do not associate calibrated profile. Use Firefox. The key here is probably a DE with Color management capability which is being turned ON, with no calibrated profile loaded for the monitor. Gnome and Unity are very typical for this (Unity uses Gnome control schemes). They all have CMS capability, they all turn CMS on by default, they all auto-generate ICC profiles and associate them with the monitors, triggering Firefox to do color management (in a wrong way). On Windows: Install a driver from your monitor’s manufacturer, do not associate calibrated profile. Use Firefox. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #26 from Tyson Tan --- Created attachment 100882 --> https://bugs.kde.org/attachment.cgi?id=100882&action=edit Philips 190EL's ICM from its driver Maybe we can compare this with PA242's and Ubuntu auto-generated ones. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #20 from Tyson Tan --- Hi Boud, I'm pretty sure it happens on Windows 10 + Firefox. I actually noticed this problem first time on Windows 10, then I went to test it on Gnome. All of them have this problem. I'll answer other questions later. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #19 from Tyson Tan --- Hi Elle, I couldn't find any sRGB profile download on Adobe's website, either. And yes the sRGB profile we have been using is indeed from HP. Must be me remembering things wrong or they have changed (my last research on sRGB under Windows was around 2012). Either way, I'm sorry about the misinformation. I DIDN'T request to keep the box UNCHECKED EVERY TIME. My intention was to uncheck it THE FIRST TIME when we use that dialogue on a FRESHLY installed Krita. Krita remembers that option so they can keep it checked if they like. My opinion is: just don't guide unknowing people into the trap. Artists are not part of the problem. Most non-tech artists will never change default settings. They are unlikely to notice the color shift problem. Even if they do noticed, they are unlikely to link the problem with that checkbox. They will only blame Krita because "it is the only app that make wrong colored picture". -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #14 from Tyson Tan --- Hi Elle, MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also provides a color profile download that includes sRGB and AdobeRGB profiles. Last time I checked, the said sRGB profiles was produced by ICC in the meta information. Ubuntu also has a similar sRGB profile to generate default ICC for everything. If you cannot find them, I can extract them later for you. I agree with your idea to make a new option that reads like “Workaround broken color management of some OS”, which is checked by default, does whatever necessary to make sure the exported picture shows correct color everywhere. As for the technical stuff... look at all those parties you’ve mentioned. Because of the horrible foundation they laid, everybody now has developed their own ways to coupe with the problem. You change one thing upstream, you break everybody downstream. I bet they’d rather remain the current state. Although I can understand everything in this conversation so far, I’m just a desperate artist who was forced to learn stuff that’s not in my legit territory. I’ll do whatever I can to help the research, but our research will take time. I understand the ideal solution indeed SHOULD be done by the upstreams, but in reality it probably won’t be there in a few years. Meanwhile, the artists use Krita probably have deadlines to beat and cannot wait that long. The cheapest workaround is simple: change the default value of “Embed sRGB profile” to UNCHECKED, and ideally add some explanation text below so people don’t try to be smart by checking it. We are already doing that for JPG, why not PNG too? I understand that as a developer, you want things to work according to the standard with a correct process. But in reality, people just want to see right color. It’s so frustrating seeing my own pictures displayed and printed with wrong color, probably losing potential clients as well. Although I know how to avoid it now, it still breaks my heart seeing fellow Krita artists unknowingly suffering the same. Please help them! Hi Elle, MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also provides a color profile download that includes sRGB and AdobeRGB profiles. Last time I checked, the said sRGB profiles was produced by ICC in the meta information. Ubuntu also has a similar sRGB profile to generate default ICC for everything. If you cannot find them, I can extract them later for you. I agree with your idea to make a new option that reads like “Workaround broken color management of some OS”, which is checked by default, does whatever necessary to make sure the exported picture shows correct color everywhere. As for the technical stuff... look at all those parties you’ve mentioned. Because of the horrible foundation they laid, everybody now has developed their own ways to coupe with the problem. You change one thing upstream, you break everybody downstream. I bet they’d rather remain the current state. Although I can understand everything in this conversation so far, I’m just a desperate artist who was forced to learn stuff that’s not in my territory. I’ll do whatever I can to help the research, but our research will take time. I understand the ideal solution indeed SHOULD be done by the upstreams, but in reality it probably won’t be there in years. Meanwhile, the artists use Krita probably have deadlines to beat and cannot wait that long. It’s frustrating seeing my own pictures displayed and printed with wrong color, probably losing potential clients as a result as well. Now I know how to avoid it myself, it still breaks my heart seeing fellow Krita artists unknowingly suffering the same. The cheapest workaround is simple: change the default value of “Embed sRGB profile” to UNCHECKED, and ideally add some explanation text below so people don’t try to be smart by checking it. We are already doing that when exporting JPG, why not PNG too? I understand that as a developer, you want things to work according to the standard with a correct process. But people just want to see nice result. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #15 from Tyson Tan --- Oops, Comment 14 got double pasted. Here is the correct version. Hi Elle, MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also provides a color profile download that includes sRGB and AdobeRGB profiles. Last time I checked, the said sRGB profiles was produced by ICC in the meta information. Ubuntu also has a similar sRGB profile to generate default ICC for everything. If you cannot find them, I can extract them later for you. I agree with your idea to make a new option that reads like “Workaround broken color management of some OS”, which is checked by default, does whatever necessary to make sure the exported picture shows correct color everywhere. As for the technical stuff... look at all those parties you’ve mentioned. Because of the horrible foundation they laid, everybody now has developed their own ways to coupe with the problem. You change one thing upstream, you break everybody downstream. I bet they’d rather remain the current state. Although I can understand everything in this conversation so far, I’m just a desperate artist who was forced to learn stuff that’s not in my territory. I’ll do whatever I can to help the research, but our research will take time. I understand the ideal solution indeed SHOULD be done by the upstreams, but in reality it probably won’t be there in years. Meanwhile, the artists use Krita probably have deadlines to beat and cannot wait that long. It’s frustrating seeing my own pictures displayed and printed with wrong color, probably losing potential clients as a result as well. Now I know how to avoid it myself, it still breaks my heart seeing fellow Krita artists unknowingly suffering the same. The cheapest workaround is simple: change the default value of “Embed sRGB profile” to UNCHECKED, and ideally add some explanation text below so people don’t try to be smart by checking it. We are already doing that when exporting JPG, why not PNG too? I understand that as a developer, you want things to work according to the standard with a correct process. But people just want to see correct result. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #12 from Tyson Tan --- Hi wolthera, this problem has been bugging me for a very long time. I know you probably already knew it, but there was no public article to explain it. I reported it with detail anyway so other less experienced users might learn something as well. One of these days other people will bump into this issue and this bug report can be used to explain stuff. Anyway if we can just turn OFF Embed sRGB option for Saving PNG, there will be much less user got their pictures messed up in Firefox. What's more, I highly suspect this ICC issue is going to impact Krita's pre-printing oriented users as well -- the whole printing process is completely color-managed! I noticed many of my pictures made with Krita, when being printed by the factories, had similar color shift. The blacks were never as black as what's in Krita. I thought it was normal to have such RGB-CMYK color loss and I just need to be more experienced to do better color planning. But recently one of my pictures got manipulated to add text before getting printed, and it didn't have the same color shift. They used proprietary software for that task. I guess it reveals how scary this issue can be for the professionals. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #10 from Tyson Tan --- You can get ICC official sRGB profiles from its website: http://www.color.org/srgbprofiles.xalter I hope we can find some differences regarding to the sRGB ICC color management problem that has been confusing us for so long. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #9 from Tyson Tan --- Created attachment 100776 --> https://bugs.kde.org/attachment.cgi?id=100776&action=edit Properly calibrated ICC profile of Wacom Cintiq 13HD -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #8 from Tyson Tan --- Created attachment 100775 --> https://bugs.kde.org/attachment.cgi?id=100775&action=edit Properly calibrated ICC profile of NEC PA242W -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #7 from Tyson Tan --- Created attachment 100774 --> https://bugs.kde.org/attachment.cgi?id=100774&action=edit Windows 10 system default ICC profile of NEC PA242W -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #6 from Tyson Tan --- Created attachment 100773 --> https://bugs.kde.org/attachment.cgi?id=100773&action=edit Gnome 3 System default ICC profile of Wacom Cintiq 13HD -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #5 from Tyson Tan --- Created attachment 100772 --> https://bugs.kde.org/attachment.cgi?id=100772&action=edit Gnome 3 System default ICC profile of NEC PA242W -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #4 from Tyson Tan --- Created attachment 100771 --> https://bugs.kde.org/attachment.cgi?id=100771&action=edit Response curve of system default ICC profile -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #3 from Tyson Tan --- Created attachment 100770 --> https://bugs.kde.org/attachment.cgi?id=100770&action=edit Kiki picture exported without embedded sRGB profile -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #2 from Tyson Tan --- Created attachment 100769 --> https://bugs.kde.org/attachment.cgi?id=100769&action=edit Kiki picture exported with embedded sRGB profile -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #1 from Tyson Tan --- Created attachment 100768 --> https://bugs.kde.org/attachment.cgi?id=100768&action=edit Comparison of a sensitive picture with or without embeded sRGB profile This is a comparison of a sensitive picture with or without embeded sRGB profile. The left one has embedded sRGB profile, the right one has not. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] New: Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 Bug ID: 367832 Summary: Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more. Product: krita Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com Krita has the ability to embed the current sRGB profile during exporting to PNG and JPG. By default, the checkbox for this function is ON for PNG, OFF for JPG. However, saving with Krita's embedded sRGB profile (I assume it’s sRGB-elle-V2-srgbtrc.icc) leads to undesired color shift when the picture is being viewed with a Color Management enabled viewer (notably Firefox) under certain widely happening OS environment. This is not a Krita bug, nor a Firefox bug. It’s caused by a problematic way our industry has been handling the default ICC profile for displays. Here I will discuss what triggers it and suggest how Krita can work around this by changing a single default saving value. Reproducible: Always Steps to Reproduce: 1) Krita exported PNG with the Embedded sRGB profile checkbox checked; or Save ICC profile checked for JPG. I assume it embeds sRGB-elle-V2-srgbtrc.icc. This is not the official sRGB profile from ICC. 2) OS has its Color Management Enabled. I can confirm that Windows 10 and Gnome 3 has Color Management ON by default. Most most modern OS should have this ON by now. 3) OS recognized the current display and automatically installed drivers accordingly. On Windows the driver is just a place holder for PNP device. It comes with a default ICC profile. On Gnome 3, gnome-color-manager automatically generates a similar ICC profile and assign it to the display. 4) This mystical ICC profile, which I often regard as “the fake ICC Profile”, no matter on Windows or Gnome, has a increased RED responsive curve. If an image viewer respect this ICC profile, the picture becomes slightly brighter, pinkish, and has less contrast. Blue color takes the heaviest impact. 5) Users do not manually assign a correctly calibrated ICC profile to the display, nor do they remove the "fake ICC" or turn the Color Management of the OS off. If they do any of these, the color shift will not happen. But I think 99% people will never do. 6) Most image viewers do not do color management by default. So there is no color shift when using them. 7) But Firefox, one of the most popular web browser, has its Color Management ON by default. So if 1) ~ 5) is happening (which is 99% the case) and they are using Firefox, the color shift will happen. Which means a lot of people are affected. 8) Firefox use “gfx.color_management.mode” to control it Color management behavior in “about:config” page. The default value is 2, meaning Firefox only does Color Management if the picture has an non sRGB Embeded ICC profile. If we set this value to 1, then all pictures, regardless of having an embedded ICC or not, will be color managed. You may find more information here: http://kb.mozillazine.org/Gfx.color_management.enabled 9) Firefox detects the embedded ICC profile of the picture. If it's sRGB, it will not color manage it, hence no color shift. Adobe Photoshop's sRGB embedded picture is not affected because Photoshop embeds the official sRGB profile from ICC. Krita is affected because sRGB-elle-V2-srgbtrc.icc is not official and Firefox consider it to be a calibrated ICC. Actual Results: So all and all, Firefox is doing its job according to the rules, while the OS is supplying it with a wrong reference, causing the color shift to happen. There is nothing we can do about it unless the ICC people realized it. Or they did this for some unknown reason. Expected Results: Although it's technically not Krita's fault, we can do something to avoid being affected. So far Krita saving as JPG has ICC off by default, which is a good thing. All we need is to turn off ICC for PNG (and all other universal formats that has the ability to embed ICC). The other way is of course to embed the non-free sRGB profile from ICC. Which I don't think being possible. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #17 from Tyson Tan --- New found easy workaround: When cursor stuck at mouse mode, move the cursor out of the canvas onto the toolbar/titlebar of the Krita window, then return to canvas -- the cursor is now back to normal. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363225] Qt5 under Linux get stuck in "clicking" state, and Krita become unusable
https://bugs.kde.org/show_bug.cgi?id=363225 --- Comment #21 from Tyson Tan --- Also related to this bug is Bug 363283. I'm using appimage 3.0.1 beta on Ubuntu Gnome 16.04.1. That bug still happens from time to time, although it doesn't feel as frequent as when I reported it, or it's just because I've found a very easy work around for it -- when it stuck to cursor mode, move the cursor out of the canvas and then move back -- it's free now. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 355976] Brush stroke signal lost with krita-lod-unstable
https://bugs.kde.org/show_bug.cgi?id=355976 --- Comment #6 from Tyson Tan --- Hi Dmitry, I don't see this bug anymore for a very long time. 9 out of 10 it was a Ubuntu 15.04 specific bug -- it had very old Qt packages. I think you've fixed it in the recent builds. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #16 from Tyson Tan --- Hi Camille, I can reproduce Comment 8 in Bug 363225. I commented there. It really felt like these 2 bugs are related somehow, because both happened after an icon shift. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363225] Qt5 under Linux get stuck in "clicking" state, and Krita become unusable
https://bugs.kde.org/show_bug.cgi?id=363225 Tyson Tan changed: What|Removed |Added CC||tyson...@mail.com --- Comment #17 from Tyson Tan --- I can reproduce Comment8, too. But in my case, only a middle click can release Krita from the move lock state. Tested on Ubuntu Gnome Edition 16.04, Krita 3.0 from Krita Lime PPA, Intuos4. I don't have a touch sensitive tablet so I couldn't test comment7. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #14 from Tyson Tan --- Created attachment 99748 --> https://bugs.kde.org/attachment.cgi?id=99748&action=edit Test file for BUG363283 I was testing using this document. I hope you can reproduce the bug using it! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #13 from Tyson Tan --- Created attachment 99745 --> https://bugs.kde.org/attachment.cgi?id=99745&action=edit Mouse cursor appears after saving when brush tool is in use I managed to capture a video for this bug at work because I can trigger it every time when I try in this session, for unknown reason. Normally it doesn't happen a lot in the beginning of a Krita session, but after a while it gets really often, like what I did in this video. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #12 from Tyson Tan --- I've done a few now tests on Ubuntu 16.04, and found a pattern that triggers the bug very easily: 1. Select Eraser_circle, erase something; 2. Save the change with Ctrl+S When the save dialogue is finished, the normal mouse cursor will appear. Apparently, the longer Krita stay opened, the more you use save, the more often the mouse cursor appears, until it happens every time you do a save. At least it has something to do with that SAVE dialogue, I guess? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #11 from Tyson Tan --- I've tested it on Windows 10. Could not reproduce the bug there. So it's probably a Ubuntu 16.04 specific bug. Also, Krita 3.0 beta didn't have this bug either. But again, it could be the old betas were running on Ubuntu 15.10. I don't know. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #10 from Tyson Tan --- Recently I have been primarily working on pixel art, never once did this bug happen. But once I return to print size pictures, I see this bug ALL THE TIME. Right now I'm using only Intuos4 with an normal monitor, drawing a picture the size of about 5700x2600, using a memory of 258MB. It happens almost every time I toggle something. Thus, I think it's not related to a certain tablet, but definitely has something to do with resolution. I have to revert to Krita 2.9 for now. There is no way I can keep my flow going with a constant distraction like that. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364290] Auto canvas extending might cause canvas contently moving to an edge
https://bugs.kde.org/show_bug.cgi?id=364290 --- Comment #1 from Tyson Tan --- Created attachment 99488 --> https://bugs.kde.org/attachment.cgi?id=99488&action=edit Krita being locked in extreme position when large layer is moved over the boundary of canvas -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364290] New: Auto canvas extending might cause canvas contently moving to an edge
https://bugs.kde.org/show_bug.cgi?id=364290 Bug ID: 364290 Summary: Auto canvas extending might cause canvas contently moving to an edge Product: krita Version: 3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com Auto canvas extending might cause canvas contently moving to an edge. It seems to occur only when the document/layer is larger than certain size with very high zoom in rate. Reproducible: Always Steps to Reproduce: 1. Make a 1680x1050 screenshot 2. Open said screenshot 3. Duplicate Layer 1 4. Zoom in to 1131%, pan to the right edge of canvas 5. Move tool, drag the duplicated layer to right extreme Actual Results: Now the canvas is locked to extreme position. Dragging scroll bars, Middle mouse button, hand tool... they all don't work. Any pan in the canvas, it bounces back to extreme position within milliseconds. Click ">" to cancel auto extending doesn't help. Only until closing the document can restore Krita's usability. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364289] Mirror Mode always initiates with axis at the center of the 2nd document on the canvas of the 1st document
https://bugs.kde.org/show_bug.cgi?id=364289 --- Comment #1 from Tyson Tan --- Created attachment 99487 --> https://bugs.kde.org/attachment.cgi?id=99487&action=edit Krita use fixed axises position across all document tabs. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364289] New: Mirror Mode always initiates with axis at the center of the 2nd document on the canvas of the 1st document
https://bugs.kde.org/show_bug.cgi?id=364289 Bug ID: 364289 Summary: Mirror Mode always initiates with axis at the center of the 2nd document on the canvas of the 1st document Product: krita Version: 3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com When 2 documents are opened at the same time, "Set horizontal Mirror Mode" and "Set vertical Mirror Mode" always initiates their axises at the center of the 2nd document, even when we are using them on the 1st canvas. This bug is worse when the dimensions of the 2nd document is more than 2X larger than the 1st document -- the axises are initiated outside the canvas and thus cannot be seen or dragged. Causing great confusion. (at some point I thought the customizable axis feature was canceled because of this bug) Reproducible: Always Steps to Reproduce: 1. Create 1st document, size: 256x256 2. Create 2nd document size: 512x512 3. Switch to 1st document 4. Press "Set horizontal Mirror Mode" and "Set vertical Mirror Mode". Actual Results: Axises are initiated on the edge of 1st document. Expected Results: Axises should always be initiated at the center of a document. Each opened document should have their own separated parameter on Mirror Mode axises. Can also be triggered using another way: 1. Create 1st document, size: 256x256 2. Press "Set horizontal Mirror Mode" and "Set vertical Mirror Mode". 3. Create 2nd document size: 512x512 4. Switch to 1st document The result: the axises of the 1st document automatically pushed to the edge match the situation of the 2nd document on pixel level. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364167] Make it possible to adjust letter spacing and line spacing in Mutipleline text tool
https://bugs.kde.org/show_bug.cgi?id=364167 --- Comment #3 from Tyson Tan --- Great! Looking forward to the implementation! Although I haven't seen any description of your plan about ling/letter spacing. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364167] New: Make it possible to adjust letter spacing and line spacing in Mutipleline text tool
https://bugs.kde.org/show_bug.cgi?id=364167 Bug ID: 364167 Summary: Make it possible to adjust letter spacing and line spacing in Mutipleline text tool Product: krita Version: 3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Vector Objects and Tools Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com This goes to the wishlist. When we plan the new vector engine for Krita 3.1, I hope we can make it possible to adjust letter spacing and line spacing in Mutipleline text tool. They are essential for flexible typography. GIMP has these abilities, but unfortunately they are plagued by using libfreetype/fontconfig settings directly from system//OR//$HOME, bringing up so much intricacies. I hope we don't make the same mistakes! Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363535] Missing cursor icon of shear free transformation
https://bugs.kde.org/show_bug.cgi?id=363535 --- Comment #1 from Tyson Tan --- Created attachment 99193 --> https://bugs.kde.org/attachment.cgi?id=99193&action=edit Shear of Free transformation tool has no cursor icon -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363535] New: Missing cursor icon of shear free transformation
https://bugs.kde.org/show_bug.cgi?id=363535 Bug ID: 363535 Summary: Missing cursor icon of shear free transformation Product: krita Version: 3.0 Release Candidate Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com When doing free transformation, dragging the lines between the nodes can shear (skew in PS?). However, the cursor icon for such action is now missing and only a normal mouse cursor is displayed. Krita can't hint a user about its ability to do this without a cursor icon, so it's kinda a problem. Will upload a photo later. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #9 from Tyson Tan --- Dmitry: Ubuntu 16.04 -- which I was using when I reported the bug -- has Qt 5.5.1 though. I'm running on intuos4+Cintiq12HD+1normal display (dual screen). I don't recall seeing this when Cintiq12HD was unplugged. I don't recall seeing this when doing very low-res pixel art (smaller than 640x480). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362712] Crash when switching OpenGL on/off
https://bugs.kde.org/show_bug.cgi?id=362712 --- Comment #6 from Tyson Tan --- Thank you, Boud! :D -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 --- Comment #1 from Tyson Tan --- Created attachment 99074 --> https://bugs.kde.org/attachment.cgi?id=99074&action=edit Mouse cursor displayed when brush tool in use When taking this photo, I was pressing Ctrl to pick color, and you can see the cursor stuck as normal mouse cursor, not a color picker icon. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 363283] New: Mouse cursor occasionally being displayed in brush mode
https://bugs.kde.org/show_bug.cgi?id=363283 Bug ID: 363283 Summary: Mouse cursor occasionally being displayed in brush mode Product: krita Version: 3.0 Release Candidate Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com On a local build of krita3-testing_2+git20160517+r15-67~ubuntu16.04.1, my mouse cursor occasionally appears when brush tool is in use. This is not supposed to happen as it blocks the brush area. So far I could not figure out what triggered it. But I'm sure it didn't happen with the previous PPA krita3-testing packages. My executed operations includes: 1. Brush mode in use; 2. Mirror Mode toggled; 3. Eraser Mode toggled; 4. Selecting different layers; 5. Move canvas; 6. Ctrl+LMB pick color. Tested on Ubuntu Gnome Edition 16.04. Print screen button could not capture the cursor. I will upload a photo later. Switching to other tools, doing any window actions will eliminate the cursor. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362730] Instant preview makes Ctrl+LMB color picking unresponsive
https://bugs.kde.org/show_bug.cgi?id=362730 --- Comment #9 from Tyson Tan --- Thank you, Dmitry! :D -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362730] Instant preview makes Ctrl+LMB color picking unresponsive
https://bugs.kde.org/show_bug.cgi?id=362730 --- Comment #5 from Tyson Tan --- Created attachment 98833 --> https://bugs.kde.org/attachment.cgi?id=98833&action=edit Krita 3.0 beta Instant Preview drawing artifact Apparently, it was not an Undo/Redo related artifact, it's a canvas drawing artifact. As you can see in this video, Instant Preview is actually making the canvas drawing much slower. The progress bar took seconds to finish. When I turn Instant Preview OFF, then there is no delay at all. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362730] Instant preview makes Ctrl+LMB color picking unresponsive
https://bugs.kde.org/show_bug.cgi?id=362730 --- Comment #4 from Tyson Tan --- It probably has something to do with the size of the document. It happened to a 5500x6000px, 3 layers, 500M memory usage document. Maybe not the first few picking, but the picking will fail after a few strokes. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362730] Instant preview makes Ctrl+LMB color picking unresponsive
https://bugs.kde.org/show_bug.cgi?id=362730 --- Comment #3 from Tyson Tan --- Created attachment 98832 --> https://bugs.kde.org/attachment.cgi?id=98832&action=edit Krita 3.0 beta Instant Preview related Ctrl Color picking issue test file -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362730] Instant preview makes Ctrl+LMB color picking unresponsive
https://bugs.kde.org/show_bug.cgi?id=362730 --- Comment #2 from Tyson Tan --- Created attachment 98831 --> https://bugs.kde.org/attachment.cgi?id=98831&action=edit Krita 3.0 beta Instant Preview related Ctrl Color picking issue video -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362712] Crash when switching OpenGL on/off
https://bugs.kde.org/show_bug.cgi?id=362712 Tyson Tan changed: What|Removed |Added CC||tyson...@mail.com --- Comment #1 from Tyson Tan --- This happened to me on Ubuntu 16.04 Gnome Edition. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362134] Alternative shortcuts breaks primary shortcuts in Krita 3.0 alpha.
https://bugs.kde.org/show_bug.cgi?id=362134 --- Comment #6 from Tyson Tan --- Yes, it's fixed. Thank you everyone! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362730] New: Instant preview makes Ctrl+LMB color picking unresponsive
https://bugs.kde.org/show_bug.cgi?id=362730 Bug ID: 362730 Summary: Instant preview makes Ctrl+LMB color picking unresponsive Product: krita Version: 3.0 Beta Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com In Krita 3.0 Beta, when Instant preview is enabled, Ctrl+LMB to pick color is not very responsive. I often need to keep Ctrl+LMB pressed down, wait for a second until a new color is picked. This pretty much makes Ctrl+LMB color picking useless. It gets more obvious when: 1) the picture is big; 2) a big brush stroke was just applied (and probably still not finish drawing); 3) a brush stroke was just undone. It feels like Qt OpenGL queue congestion to me. Instant Preview is causing so much problem now: 1) Undo/Redo has visual glitches; 2) This bug; 3) Overall slowdown and more. Are these normal by design for enabling instant preview? Or they are issues to be addressed? Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 343762] Crop Tool handles trapped within last-used range after undoing when multiple documents are opened
https://bugs.kde.org/show_bug.cgi?id=343762 --- Comment #4 from Tyson Tan --- Hi Dmitry, That "restore previous crop" feature, does Krita 2.9.x on PPA have it? I'm quite sure that I saw some crop boundary bugs in action using Krita 2.9, 20160202build on PPA. I assume upon 2016-02-02, either Bug 343722 or this bug had not been completely fixed. And the crop handles are often shown incorrectly these days. I didn't have time to do a through test though. I will retest this using Krita 3.0 beta later. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362217] Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha
https://bugs.kde.org/show_bug.cgi?id=362217 --- Comment #9 from Tyson Tan --- Hi Dmitry, I confirmed the fix using the lastest PPA package, they worked beautifully. It will keep my sanity up XD Thank you so much! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362217] Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha
https://bugs.kde.org/show_bug.cgi?id=362217 --- Comment #8 from Tyson Tan --- Hi Dmitry, Panning is good. The point to use middle-click to shift focus to canvas is exactly to make zooming available with panning. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362217] Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha
https://bugs.kde.org/show_bug.cgi?id=362217 --- Comment #6 from Tyson Tan --- Thank you very much Dmitry! That's exactly what we need! I will test this as soon as the PPA is updated accordingly. And I wonder, if we can return the input focus to the canvas by using Middle-click (move canvas) as well? That's a very common habit when we draw as well. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362217] Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha
https://bugs.kde.org/show_bug.cgi?id=362217 --- Comment #4 from Tyson Tan --- I didn't check if there was a similar old bug reported. But such annoyance never felt so obvious before. It could be me using Intuos more recently, tho. This is how I arrange my workspace: [SCREEN] [KEYBOARD] [INTUOS] So each time I need to press a shortcut with a modifier (need both hands, one holding the stylus), the cursor moves out of the canvas as my hand moved over the tablet upward to press the keyboard. Earlier this year I used Cintiq more because I sketched more, the workspace was like: [CINTIQ] [KEYBOARD] It didn't happen as often as the Intuos arrangement, because when using Cintiq, it's easier and more intuitive to lift the stylus vertically as the screen angled, parallel to the arms. If I did reported a duplicated bug, I'm sorry. But I think this is a bug that impacts user experience in a very bad way -- it's too unpredictable and often being interpreted as the program not being responsive (such as I thought before, as well). Krita's UI never hinted users where to put the cursor when carrying out different tasks, making the confusion even worse, unless they know this bug. I wonder if we can do something about this before Krita 3.1 comes out? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362074] In Krita 3.0 alpha, Shortcut Setting dialogue should have the Action trees expanded by default
https://bugs.kde.org/show_bug.cgi?id=362074 --- Comment #4 from Tyson Tan --- OK. Thank you Michael! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362217] Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha
https://bugs.kde.org/show_bug.cgi?id=362217 --- Comment #1 from Tyson Tan --- (1) is especially annoying with Intuos Pro/Cintiq, because when I reach out to the zooming shortcuts using my hands (one of them is holding the stylus), there is a high chance the cursor being moved out of the canvas unintentionally, causing the flow to break. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362217] New: Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha
https://bugs.kde.org/show_bug.cgi?id=362217 Bug ID: 362217 Summary: Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha Product: krita Version: 3.0 Alpha Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com Input event not being correctly recognized when cursor is or not over certain elements in Krita 3.0 alpha. For example: 1. Zooming shortcuts (Ctrl+=/+/1, +/-) not working when cursor is not on canvas; 2. Keyword filter input box in brush preset widget, when cursor moves onto canvas (without clicking) all keyword input is interpreted as canvas shortcut; We very often use zooming during operations like changing Brushes, Color adjustment, Transformation, and switching back and forth between another program to look at references. It's unpredictable where the cursor will be when we switch our focus back to drawing. With behavior like (1), zooming cease to work without any context, which is very annoying and breaks the flow. When using a graphics tablet, it's not easy to keep the cursor inside the input box when typing a keyword. It's not like using a mouse, with which you can stop anytime, a stylus instead keeps reporting its position until it's lifted high enough. For intuos pro/Cintiq, the effective range is more than 7mm high. Even if I try to lift it up vertically, it MUST have move the cursor somewhere! Behavior like (2) is really confusing and flow breaking as a result. There must be more than these two, but they are by far the most serious flow breakers for me. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362134] New: Alternative shortcuts breaks primary shortcuts in Krita 3.0 alpha.
https://bugs.kde.org/show_bug.cgi?id=362134 Bug ID: 362134 Summary: Alternative shortcuts breaks primary shortcuts in Krita 3.0 alpha. Product: krita Version: 3.0 Alpha Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com In krita3-testing_2+git20160422+r10-67~ubuntu16.04.1_amd64, after adding an alternative shortcut, krita fails to recognize the primary one -- it becomes empty, and remains that way. I cannot change or reset. Alternative ones works fine. Maybe the configuration for primary shortcuts is broken? Is this related to https://bugs.kde.org/show_bug.cgi?id=361325 ? Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362074] In Krita 3.0 alpha, Shortcut Setting dialogue should have the Action trees expanded by default
https://bugs.kde.org/show_bug.cgi?id=362074 --- Comment #2 from Tyson Tan --- Created attachment 98510 --> https://bugs.kde.org/attachment.cgi?id=98510&action=edit Krita 3.0 alpha shortcut settings desired result after keyword search -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362074] In Krita 3.0 alpha, Shortcut Setting dialogue should have the Action trees expanded by default
https://bugs.kde.org/show_bug.cgi?id=362074 --- Comment #1 from Tyson Tan --- Created attachment 98509 --> https://bugs.kde.org/attachment.cgi?id=98509&action=edit Krita 3.0 alpha shortcut settings not expanding upon search -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362074] New: In Krita 3.0 alpha, Shortcut Setting dialogue should have the Action trees expanded by default
https://bugs.kde.org/show_bug.cgi?id=362074 Bug ID: 362074 Summary: In Krita 3.0 alpha, Shortcut Setting dialogue should have the Action trees expanded by default Product: krita Version: 3.0 Alpha Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com In Krita 3.0 alpha, Settings>Configure Krita>Keyboard Shortcuts dialogue now displays Action tree as collapsed by default. This is not intuitive because when a user searches a keyword, he can only see the menus that include such actions, but the actual actions are hidden. Not everybody knows how to click and expand the action tree, so people might fail to customize their shortcuts. I suggest we keep the action tree expanded always, so that when we search, we can see every action that hits. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #39 from Tyson Tan --- Thanks! Silly me to think 16.04 would have included the newest Qt...as if they ever did! lol -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #37 from Tyson Tan --- Just tested Krita3-testing (2+git20160407+r9-67~ubuntu16.04.1) from Krita Lime PPA on Ubuntu 16.04. The slowdown did not happen. Well I don't know what is happening anymore XD Anyway. I will be using krita3-testing from now on (unless it has major malfunction), and report the bugs I encountered. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #36 from Tyson Tan --- Thank you! Please update the Krita Lime PPA so I can test them. Krita 3.0 builds are only available for 16.04 so I upgraded to it, but Krita 2.9.11 from that PPA is not installable as it requires libgsl0ldbl (>=1.9), while Ubuntu 16.04 LTS supplies libgsl2 (2.1+dfsg-2). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #33 from Tyson Tan --- I mean, I built my own binaries from the source code on Ubuntu 15.10, and it still has the same problem. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #31 from Tyson Tan --- But I'm using Ubuntu 15.10, it has Qt 5.4.2 with it. Both AppImage and my local build had this problem, while Windows version seems to work fine. I'm not very sure about the speculation in Comment 30. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 340948] Crash when undoing a 16 bits float to 8 bits color space conversion
https://bugs.kde.org/show_bug.cgi?id=340948 --- Comment #6 from Tyson Tan --- When I reported this, it must have happened multiple times. But during the making of that Kiki picture with cityscape, Krita color management problem caused great loss, I therefore reverted to the safest sRGB 8Bit approach. Haven't been testing this bug since. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #27 from Tyson Tan --- GPU wise you may consider: AMD Radeon R7 360 -- basically the same chipset as AMD Firepro W5100, supports D3D 12, OpenGL 4.5 and OpenCL 2.0, with a TDP of 100W, requires a 6pin power supply. Price range: $109. AMD Radeon HD 6570 -- basically the same chipset as AMD Firepro V4900, supports D3D 11, OpenGL 4.4 and OpenCL 1.2, with a TDP of 60W, doesn't require a 6 pin power supply and has a smallform factor. Price range: $39. I have been using their equivalent AMD Firepro cards, so I suppose they won't give you hard times under GNU/Linux. Personally, I would recommend HD 6570 because it's cheaper, cooler and has well-matured open source drivers. It should be much easier to manage. As for CPU (APU): AMD A8-7600, the most popular APU in recent AMD generations, supports AVX, has an integrated R7 GPU so you might save the GPU. TDP 65W. Price range: $109($79 at constant sale). Use with an A88X chipset motherboard. I suggest ASUS A88XM-A, it might give you less trouble because of a potentially better BIOS. Price range: $149. The APU plan is probably better because you may want to test against every aspect of AMD's shenanigans. XD -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #24 from Tyson Tan --- Created attachment 98370 --> https://bugs.kde.org/attachment.cgi?id=98370&action=edit Recored desktop video of Krita 2.9.11 drawing when OpenGL is ON -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #23 from Tyson Tan --- Created attachment 98369 --> https://bugs.kde.org/attachment.cgi?id=98369&action=edit Recored desktop video of Krita 3.0 alpha lags when OpenGL is ON -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #22 from Tyson Tan --- Correction for Comment 21: When using the Appimage version, with Crosshair cursor, Brush Outline and Instant Preview, logging options all checked, Krita crashes immediately WHEN I DRAW SOMETHING. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #21 from Tyson Tan --- Hi Dmitry, When using the Appimage version, with Crosshair cursor, Brush Outline and Instant Preview, logging options all checked, Krita crashes immediately. The terminal says "Segment fault". I don't see "glSync effectiveness" lines in the terminal when I draw long strokes. Meanwhile, I'm preparing means to record video on my PC. Will report back later. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #17 from Tyson Tan --- Tested under Windows 10 x64 on my Xeon/Firepro W5100 machine. There is no slowdown or it was very hard to notice. Curves don't become straight lines. However, the slow antialiasing described in Comment 16 is still noticeable. And the canvas updates in multiple noticeable horizontal stripes. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #16 from Tyson Tan --- Created attachment 98352 --> https://bugs.kde.org/attachment.cgi?id=98352&action=edit Krita 3.0 alpha slow antialiasing LEFT: during the stroke RIGHT: 1 second after the stroke is made -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #15 from Tyson Tan --- I've built Krita 3.0 Alpha locally, and things behave a bit differently now: 1. Krita's performance logging still fails, but it now shows "QFSFileEngine::open: No file name specified" instead. 2. Slowdowns still occur when drawing, but at least curves do not occasionally become straight lines anymore. But the canvas updates even slower. I can feel it updates only 4 or 5 times during a very long stroke. 3. It's so slow that I can see a curve stroke with zig-zag at its edge, then about 1 second later the antialiasing makes it smoother. 4. Appimage version uses GTK file dialogue. Local build uses KDE file dialogue. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #13 from Tyson Tan --- I tested mostly using Fill_circle but every preset lags. I tried enabling logging but I could find the log. Krita says it saves those in , I suppose it's the same directory where I saved the .kra file? The terminal returns: QIODevice::write (QFile, "log/Fill_block.stroke.rdata"): device not open Requested FPS: 16.4121 QIODevice::write (QFile, "log/Fill_circle.stroke.rdata"): device not open Requested FPS: 35.841 Requested FPS: 113.739 QIODevice::write (QFile, "log/Ink_gpen_10.stroke.rdata"): device not open Requested FPS: 8.15437 Requested FPS: 59.5519 Requested FPS: 123.021 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #11 from Tyson Tan --- Hi Boud, that option has no effect either. As long as OpenGL is ON, I can't find any options that can alleviate the problem. If there is more test I can do, please tell me how to. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #9 from Tyson Tan --- Hi wolthera, that option has no effect at all. I've also tested this on another PC running Xeon E3-1230v5 and AMD Firepro W5100 using proprietary driver, the result was the same. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #7 from Tyson Tan --- Tested on Ubuntu 15.10 64-Bit CPU: Intel® Core™ i5-3470 CPU @ 3.20GHz × 4 RAM: 15.6 GiB GPU: AMD Firepro V4900, opensource driver, Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.6.2) Krita 2.9 runs fine on this setup. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #6 from Tyson Tan --- Created attachment 98333 --> https://bugs.kde.org/attachment.cgi?id=98333&action=edit Krita 3.0 Alpha input not lagging when OpenGL is OFF with large window, tablet log -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #5 from Tyson Tan --- Created attachment 98332 --> https://bugs.kde.org/attachment.cgi?id=98332&action=edit Krita 3.0 Alpha input not very lagging when OpenGL is ON with small window, tablet log -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #4 from Tyson Tan --- Created attachment 98331 --> https://bugs.kde.org/attachment.cgi?id=98331&action=edit Krita 3.0 Alpha input lagging when OpenGL is ON with large window, tablet log -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #3 from Tyson Tan --- Created attachment 98330 --> https://bugs.kde.org/attachment.cgi?id=98330&action=edit Krita 3.0 Alpha input not lagging when OpenGL is OFF with large window -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #2 from Tyson Tan --- Created attachment 98329 --> https://bugs.kde.org/attachment.cgi?id=98329&action=edit Krita 3.0 Alpha input not very lagging when OpenGL is ON with small window -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 --- Comment #1 from Tyson Tan --- Created attachment 98328 --> https://bugs.kde.org/attachment.cgi?id=98328&action=edit Krita 3.0 Alpha input lagging when OpenGL is ON with large window -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361619] New: Input event lag/drop-out when OpenGL is ON with large window
https://bugs.kde.org/show_bug.cgi?id=361619 Bug ID: 361619 Summary: Input event lag/drop-out when OpenGL is ON with large window Product: krita Version: 3.0 Alpha Platform: Other OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: tyson...@mail.com In Krita 3.0 Alpha (Krita-3.0-Alpha-master-e5109c2-x86_64.AppImage), when OpenGL is ON and Krita's window is large -- 1920x1080 maximized window, or a windows that is almost that big but not maximized, I can notice input lag from my graphics tablet and mouse. Some curves I drew even has straight line sessions in them, probably due to event drop-out. When Krita's window is smaller -- around 1280x800 or 960x1080, the lagging seems to be much less noticeable. When OpenGL is OFF, the lag didn't happen at all. I will upload screenshots and tablet logs for each testcase. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 340736] Very slow performance while changing layer orders
https://bugs.kde.org/show_bug.cgi?id=340736 --- Comment #13 from Tyson Tan --- Great news. Thanks! :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 353434] Krita uses KDE file dialogues on non-Gnome-shell GTK DEs.
https://bugs.kde.org/show_bug.cgi?id=353434 --- Comment #6 from Tyson Tan --- Good news! Somehow on Ubuntu Gnome 15.10 I have never encountered this bug anymore...I wonder what triggered it last time. :b -- You are receiving this mail because: You are watching all bug changes.
