Bug 312153

Hm... I have a hard time reproducing this in a virtual machine, because in a vm all of ubuntu is incredibly slow already. I would probably need to get a piece of real hardware to install ubuntu on. It's weird that the color management using colord would cause a slowdown, though.  What happens if you uncheck "Use system monitor profile" and select the profile you selected in the colord settings as Monitor profile?

You could also try upgrading to the 2.6 beta; that should be much faster under all circumstances. the kubuntu beta ppa has 2.5.93 already.

Actually... there is no such checkbox named "Use system monitor profile" in my Krita's setting. I could not find it under Unity or KDE. I will upload the screenshots of Krita's preference window in the coming-up comment.

Choosing "sRGB built-in" monitor profile in Krita's preference window gives it full speed. Maybe it works the same as unchecking "Use system monitor profile". However, if there is an ICC profile attached in the system setting, the drop-down menu becomes a text-string that synchronized with the system's profile; therefore I cannot choose "sRGB built-in" under such circumstance.

I did some more research and discovered that if I select any other profile in Krita's preference window, say, “Compatible with Adobe RGB”, Krita will slowdown even when there is no system-wide color profile attached. This can be reproduced under KDE, too.

I will give the beta a try when I have time. Thank you for the information. I'm looking forward to the speed improvement! :)

Created attachment 76003 [details]
Krita color preference with no system profile enabled.

Krita color preference with no system profile enabled. I cannot find any checkbox named "Use system monitor profile" here. Screenshot taken in Ubuntu/Unity.

Created attachment 76004 [details]
Krita color preference with a system profile enabled.

Krita color preference with no system profile enabled. The drop-down menu becomes a text-string that synchronized with the system's profile; therefore I cannot choose "sRGB built-in" under such circumstance. Screenshot taken in Ubuntu/Unity.

Created attachment 76005 [details]
Krita color preference with no system profile enabled, under KDE.

Krita color preference with no system profile enabled, under KDE. No checkbox named "Use system monitor profile" here, either. Choose anything other than "sRGB built-in" slowsdown Krita even under KDE. Screenshot taken under Ubuntu/KDE.

Created attachment 76009 [details]
Krita 2.6 RC2 laggy brush stroke with OpenGL enabled.

I just tried Krita 2.6 RC2 from Kubuntu beta PPA. It much faster with CMS on, and it's now completely acceptable. Congratulations on the improvement here! I've also discovered the checkbox you mentioned.

It's funny though, in the newer verion Krita is slower with CMS off, although acceptable, I can still notice the "block by block" screen drawing when I fill the whole canvas with color and undo/redo many brush strokes.

And...with OpenGL on, Krita 2.6 RC2 cannot follow the brush stroke very well... :b

Hi Tyson,

Could you try updating to a more recent version of Krita (preferable git master...) I am hoping that 2.7alpha will have solved these issues for you, both the color management issue as well as the opengl painting issue.

Oh -- and has the t-shirt arrived yet?

>Boudewijn

## Color Management Slowdowns
Hi, I had built Krita 2.7 alpha from git master with Vc enabled today and saw no major slowdown when color management was turned on.  In fact, such slowdowns were almost disappeared since the release of 2.6, probably a by-product of the overall performance boost from that branch. On an A4@300dpi sized canvas, the color bucket tool can now fill the whole area within a second, which is totally usable and definitely a great improvement to the previous branches. 

## Drawing Strokes Artifact (very slight)
In 2.7 alpha, I noticed that some artifacts appear around the strokes while drawing using a large paintbrush. Fortunately they would not stay on the canvas as Krita finished drawing its screen. On my laptop, this takes about 0.1~0.5 sec for the application to keep up my quickest brush movement.

## OpenGL related issues
OpenGL has been very problematic since 2.6. So did Krita 2.7 Alpha. When I turned OpenGL on, filling a canvas was performed almost immediately; however, when I tried to draw with my paintbrush, a new problem occurred – the application did not seem to be able to follow my brush movements, either using tablet or mouse, the result was some very funny strokes (I will attach a screenshot about this issue).

I'm using an helplessly impotent 1st-gen intel HD Graphics on i7-620LM, the best I could do was to install the newest driver from intel's 01.org. But updating the driver did not seem to help. I couldn't test this against my much more powerful Nvidia Geforce 550Ti because my desktop machine has been dead for months. :b

## Krita T-shirts
Yes, I had received them. Thank you so much for including a Krita team T-shirt, too! Both of them are gorgeous! I showed them to my family and some friends, and they were both happy and suprise to see my artwork printed on a real object which was sent from Holland. lol

There was a funny moment when the postal office workers wouldn't let me sign for the package because my spelled name on my ID card is not exactly the same as “Tyson Tan”. Of course they didn't bother to read it in English, or they would find them very similar. It took me some effort to convince them that I was the guy. Lol

I had taken a photo of the Krita mascot t-shirt:
http://www.extvia.com/temp/krita_tshirt_s.png
I was going to post this on my tumblr, but with a second thought, I decided to post it later when my new Krita pictures are ready. I have been reading some design books, these days and therefore has become less active for a while. I hope I can contribute some cooler stuff with a solidified knowledge foundation.

Good luck on everything! ^^

Created attachment 78521 [details]
Krita 2.7 alpha unresponsive brush strokes when OpenGL enabled

Additional report:
Krita 2.7 Alpha from #project-neon PPA# has been unbearably slow, which was the main reason that I had to build my own binaries. It has been like this since ever and is actually getting worse ^^; Opening Krita 2.7 Alpha in project-neon environment could be 3 times slower than using my self-built binaries. This might not be the best way to test Krita's continuous speed improvement. (but yeah, project-neon builds are by their definition, sketchy)

ew...

if you want, you could give dmitry's Krita Lime ppa a try: http://dimula73.blogspot.nl/2013/05/krita-lime-ppa-always-fresh-versions.html.

Those are built with vc and should work best.

Hi, Boudewijn,

Thank you for the information of Krita's testing PPA. Unfortunately, it doesn't seem to work on Ubuntu 13.04 (Unity DE). Krita's icon did not show up in the launcher after installation, I guess it could be related to KDE environment variables. Actually, I have been building Krita binaries from the git-master for quite a while with Vc successfully compiled, so I think I'll keep building it myself. 

I saw Krita getting more and more responsive from 2.5 to 2.8. With OpenGL disabled, color managed canvas does not slow down significantly as before. As long as we are not sweating the application with an enormous 15000x15000 sized canvas, the response time is totally usable. You guys did a fantastic job here! ^^ I think it is time to close this bug, what do you think? 

A few days ago, an editor from an art magazine met me personally and I showed him Krita 2.8 on my laptop. He was quite impressed by Krita's brush and user interaction design. There are chances that I can get things into press that using only Krita for the digital painting part. I will definitely give Krita credit in the book if my project can ever get through! ^^

Sounds cool!

And yes, let's close the bug :-)