Pretty much exactly what it says in the title. For whatever reason, Krita 3.0 RC1's brushes simply don't seem to perform as quickly as 2.9.11's for me. Attempting to sketch in this version is clumsy to the point of near-unusability for me, as the brush is a half-second to a full second behind whatever my hand is doing. Drawing a line across the canvas results in waiting more than a second for the line to catch up to the brush. The canvas in question is here 2970x1620, so it's not like it's excessively large or anything. From what I've seen, the issue appears to effect inking and sketching brushes a lot more than painting and mixing brushes, so I think it might possibly have something to do with brush size variance. Additionally, the issue appears to get much worse when working within multiple nested group layers, resulting in even small movements lagging behind for anywhere from a 1/2 second to more than a second. Please, let me know if there's any additional information I could provide to help get this bug fixed! Reproducible: Always Steps to Reproduce: 1. Select brush 2. Attempt to paint quickly on canvas 3. Witness brush lag Actual Results: Did not draw swiftly and resposively. Expected Results: Draw swiftly and resposively.
Are you sure that the stabilizer isn't activated?
Set correct bug state.
(In reply to Boudewijn Rempt from comment #1) > Are you sure that the stabilizer isn't activated? The stabilizer isn't active at all. Activating live preview appears to help a little, but doesn't fix the problem. I seriously doubt that the stabilizer would get slower when working under multiple group layers, or freeze briefly then rush to catch up, regardless. If this helps at all, the problem seems to get progressively worse for each group layer it's nested under. To me, this seems to suggest this is some sort of layer issue, as opposed to a brush issue. I've actually put together a video demonstrating the problem: https://www.dropbox.com/s/mtkiopyo813r8y2/stream%20(01).mp4?dl=0 I've also added the link to the URL section of the bug report. What's shown in the video is actually pretty tame compared to how it's occasionally behaved when working on actual images, or just when I'm not recording it for whatever reason.
Hm, then I wonder if the problem isn't the same as in https://bugs.kde.org/show_bug.cgi?id=363320 -- this should e fixed in the most recent build: http://files.kde.org/krita/3/windows/devbuilds/krita-3.0-RC-1-master-76608ad-x64.zip . I will also make news builds tonight.
(In reply to Boudewijn Rempt from comment #4) > Hm, then I wonder if the problem isn't the same as in > https://bugs.kde.org/show_bug.cgi?id=363320 -- this should e fixed in the > most recent build: > http://files.kde.org/krita/3/windows/devbuilds/krita-3.0-RC-1-master-76608ad- > x64.zip . I will also make news builds tonight. Alright, I've tried what I believe is the latest build, labeled "krita-3.0-RC-1-master-7785651-x64.zip" and built on May 26th, according to the directory from the link you sent me. It would appear that the issue is very much still present in that version, if not actually worse.
Well... I believe I found the source of the issue, and honestly, I'm a little bit embarrassed about it. I'd started noticing weird visual anomalies and performance issues in other programs as well, and sorta put two and two together. As it turns out, it was an issue with my video card drivers. Upon updating to the latest drivers, the lag vanished. Fancy that. That said, I'll let you know if the issue comes back, since I just applied this fix a few minutes ago. ...and I'll make absolutely sure my drivers are up-to-date before filing bug reports in the future. Thanks for patiently helping me with this. Also, I'd just like to say that Krita is amazing and just keeps getting better. Keep up the good work!
What driver did you use before and after?
(In reply to Sven Langkamp from comment #7) > What driver did you use before and after? I didn't anticipate that you'd need that information, which in hindsight was kind of thoughtless of me. As a result, I'm not sure if I can tell you what the old driver was, other than that it was probably quite old, given how incredibly long it'd been since I'd updated my drivers... That said, according to the Device Manager, the version of the new driver is 16.200.1013.0, and the graphics card is an AMD Radeon R9 200 Series. If that isn't the correct info, please let me know and I'll try to retrieve the right info. If there's any way I can find out what the old driver was, please let me know and I'll get that information for you immediately.
Hi William, Thanks for checking back!
(In reply to Boudewijn Rempt from comment #10) > Hi William, > > Thanks for checking back! Well... this is unfortunate. It would appear that the driver update didn't solve the issue. It doesn't seem to be happening as frequently or as badly, but it's still enough of a problem to force me to close krita occasionally and come back later. That can really put a damper on my workflow. I've updated to newest version of krita, so I know that it hasn't necessarily been resolved in the latest build, either. Please let me know if there's any more information I can collect that might be able to go towards solving this bug.
Since you're using an AMD card, can you check whether disabling the texture buffer option makes a difference?
(In reply to Boudewijn Rempt from comment #12) > Since you're using an AMD card, can you check whether disabling the texture > buffer option makes a difference? Just tried that with what appears to be the newest build. No difference. Bizarrely enough, when attempting to test this, it took the bug the better part of an hour to manifest at all. It simply wasn't happening for awhile. I can't even begin to guess why that might be, since up until now it's appeared almost immediately after starting up the program.
Is this issue considered to be resolved in 3.0.1? Because I can confirm this problem on windows 7 with Krita 3.0.1 On a 2048 x 2048 px image, if I create a new paint layer and draw with the brush, it's fine. However, if I create 4 nested groups with a paint layer within the last group when I make a brush stroke there's a severe lag.
Given that the original poster reported that it was a problem with his video card driver, you're not having the same problem. And rendering a stroke in a four levels nested group layer is always going to be slower than rendering that stroke in a top-level layer because Krita has to calculate the result of the stroke six times: once for the paint layer, then again for every group layer and for the root group layer. Whether it's too slow to be usable or not depends on your system's specifications.
(In reply to Boudewijn Rempt from comment #15) > Given that the original poster reported that it was a problem with his video > card driver, you're not having the same problem. Thank you for the response, Boudewijin. I was under the impression that the original poster had incorrectly assumed that it was the video card driver. (William Kensinger from comment #11) >It would appear that the driver update didn't solve the issue. I'm new to bug reporting and I didn't want to create a duplicate bug. Thank you, as well, for the information about the layer rendering. I was unaware of that bottleneck and that explains a lot. > Whether it's too slow to be usable or not depends on your system's > specifications. My machine has 32 gigs of ram, I'm using a GTX 970 with the latest driver, and I'm using a separate SSD for the swap file. Even in a blank file with just 4 groups, a simple brush becomes unusable (and yes, I've tried toggling off OpenGL and made sure instant preview mode is disabled). Now that I'm aware of this limitation, I no longer utilize nested groups. Krita is fantastic, and I'm really impressed with it, but that seemed like very unexpected behavior, which is why I wanted to join this community and mention what I thought was a bug.
Hum, those are pretty good specs. My specs are probably below yours, and a quick test doesn't show any significant lag here in a nested layer group. Could you share your image with me so I can do some tests? If it's private, you can share the link with with vurian@gmail.com.
Thank you for checking Boudewijn. I did more tests and discovered it happens for some brushes, but not others. I suspect it's the brush spacing that reveals the bottleneck. When using the circle brush presets for example, a standard one like "Fill_circle" does not have discernible lag when 5 layers deep (a paint layer within 4 nested groups, that is). However, when I use another present like "ink_circle_10" the lag is significant when nested in groups, but non-existent outside of them. One of the main differences between the two is that the first one has spacing set to auto and the second's spacing is <1. Come to think of it, when I first noticed the problem I was using David Revoy's 8.1 brush presets (http://www.davidrevoy.com/article319/krita-brushkit-v8), many of which have brush spacing <1. Sure enough, when I set spacing to "auto" for "ink_circle_10," indeed the lag goes away (unfortunately, this alters the look for many brushes). This whole thing wouldn't be a problem, except that so many standard brushes have tight spacing and will not work well when nested. That is, if you can reproduce it with the same brush and it's not something with my setup. I'd be curious to know. I went a head and recorded my screen to show the problem (forgive me for using my phone, I wanted to be sure there's no question about screen recording taxing the system). https://drive.google.com/open?id=0BxKOKqLVyGC-QUR2OWZtVXp3RGs As you can see in the video, I'm using the circle brush preset, "ink_circle_10." It's a simple setup as I mentioned before; A 2k square image with 4 nested groups containing a paint layer, and one un-nested paint layer for comparison. Here's the file for safe measure: https://drive.google.com/open?id=0BxKOKqLVyGC-eXQwZGJ4Um44TEU
(In reply to Robert Showalter from comment #18) > Thank you for checking Boudewijn. I did more tests and discovered it > happens for some brushes, but not others. I suspect it's the brush spacing > that reveals the bottleneck. When using the circle brush presets for > example, a standard one like "Fill_circle" does not have discernible lag > when 5 layers deep (a paint layer within 4 nested groups, that is). However, > when I use another present like "ink_circle_10" the lag is significant when > nested in groups, but non-existent outside of them. One of the main > differences between the two is that the first one has spacing set to auto > and the second's spacing is <1. > > Come to think of it, when I first noticed the problem I was using David > Revoy's 8.1 brush presets > (http://www.davidrevoy.com/article319/krita-brushkit-v8), many of which have > brush spacing <1. Sure enough, when I set spacing to "auto" for > "ink_circle_10," indeed the lag goes away (unfortunately, this alters the > look for many brushes). > > This whole thing wouldn't be a problem, except that so many standard brushes > have tight spacing and will not work well when nested. That is, if you can > reproduce it with the same brush and it's not something with my setup. I'd > be curious to know. I went a head and recorded my screen to show the problem > (forgive me for using my phone, I wanted to be sure there's no question > about screen recording taxing the system). > https://drive.google.com/open?id=0BxKOKqLVyGC-QUR2OWZtVXp3RGs > > As you can see in the video, I'm using the circle brush preset, > "ink_circle_10." It's a simple setup as I mentioned before; A 2k square > image with 4 nested groups containing a paint layer, and one un-nested paint > layer for comparison. Here's the file for safe measure: > https://drive.google.com/open?id=0BxKOKqLVyGC-eXQwZGJ4Um44TEU Just dropping in to confirm that the bug is still happening for me under windows as of 3.1.2. I can vouch for Robert here, spacing does decrease the lag significantly for me, though it doesn't eliminate it completely. Also, I feel like this shouldn't be marked as resolved, as it's clearly still happening. Should I change the label there?