Better MacOS performance | Krita Weekly | Sept 30, 2021

There’s now a new hidden that can be enabled if you manually add useBufferInvalidation=true to your kritarc file. It should offer better performance for some CPU’s on macs. If you’re on a mac try out the newest Krita Plus/Next and test it out if you can.

That was also the openGL update that the beta 2 was waiting on too so I think there aren’t any major blockers left. But in the meantime there have also been quite a lot of bug fixing thanks to all the bug testing going on. Big thanks to @Tiar for leading that and fixing a lot of the bugs being reported there.

New Features

Better performance on OpenGL with some CPU’s on MacOS with useBufferInvalidation=true (Dmitry Kazakov)

Transform tool now supports different preview options (Halla Rempt)

Lots of improvements to the Levels filter(Deif Lou)


Fixed some older (probably around 4.0.4 to 4.1.7) .kra files using CMYK crashing the latest beta(Wolthera)

Fixed resizing brushes in the brush editor causing a crash(Dmitry Kazakov)

Bug Fixes

Fixed isometric grid forgetting cell spacing when reopening a document (Tiar)

New installs now properly read the title bar option for canvas-only mode (Reinold)

Font styles now apply correctly in the Text Tool(Artem Burjachenko)

Fixed tags sorting incorrectly after renaming(Tiar)

Fixed gradient thumbnails when creating a new bundle(Tiar)

Fixed gamut mask thumbnails after switching modes(Tiar)

Fixed first brush tip in an imported ABR file not showing up(Tiar)

Fixed cursor sometimes staying as resize icon when using the crop tool(wolthera)

Fixed sessions only able to be renamed once(Tiar)

Fixed large brush tips causing lag at start of every stroke(Dmitry Kazakov: 1 ,2 )

Made the Freehand Path Tool and Bezier Path tool work properly in Android(Sharaf Zaman)

Thanks for reading! If you like what the krita team is doing consider making a donation at It helps to keep the Krita devs working full time to make Krita better.


@Deif_Lou thanks for the taking the levels filter to next level :slight_smile:


Great news! Hopefully this should make matching plates easier. Will test.

1 Like

Thanks for the good news Reinold.

I tested the “Use texture buffer”, as you said i have a Intel CPU. I don’t know why it should only works with Intel CPU, and not for a specific GPU.
And there is no improvement for me, not for the canvas move/rotation/pen speed, and also not for the brush speed. (I thought @halla said in the past that this mode will also improves brush performance a bit, but maybe i’m wrong)

Do you maybe mean that it is only for improving OpenGL performance for macOS with an integrated Intel GPU and not if it is an Intel CPU (and don’t work for the new Apple Silicon M1)? :upside_down_face:

By the way i recognized that with the same brush, the performance with the pen tablet is less than if i draw with a mouse: Pen: 4,2 ps/ms, With the mouse: 6,2-6,5ms/px. Both for the “Wet Bristles”, 250px brush size. This is huge difference. Should i write a bug report that devs could see what is going on here?

1 Like

The “Use Texture Buffer” isn’t a new option, that’s always been there. But Dmitry and @IvanYossi did rework the way textures are uploaded and measurements show that there is quite a big improvement. Plus, I’ve been inking for hours on end on my M1 macbook pro, and I could feel and see the improvement myself.

There is a hidden, because we’re not sure how safe it is, option that you can add to the kritarc file:


When the function is enabled, the buffer is marked as invalidated right after Krita requested its uploading to the GPU texture. It should potentially increase the speed of texture uploading and reduce GPU memory footprint Krita uses.

Then start Krita from and check whether

supportsBufferInvalidation: true

is shown in the output, if so, this function is supported by your GPU.


Thank you for the clarification Halla! I’ll update the post with your correction.

Do see this difference only in Krita 5 and not Krita 4? Yes probably worth making a bug report since you can reproduce it.

Thank you very much for the clarification. Than it looks like my Radeon 580X Pro doesn’t support this, there is no output after adding this option to the rc file, and there is also no improvement for me in canvas or brush speed.

But it is nice that this should improve performance for apple m1. Then we only need improvement for the processor like neon, and i could buy an m1 in the future :wink:


I tried as well on a few Linux Intel systems and on a newish Intel Mac. I didn’t see the output after editing my kritarc file or changes in brush speed either. At the very least we can confirm it doesn’t incorrectly activate on other cpu’s :slightly_smiling_face:

The radeon GPU’s always were extremely troublesome… I still am sorry I didn’t get a dual GPU macbook pro in 2015 for testing purposes. I also do see improvements on my 2015 intel macbook pro, though it’s incredible how much faster the M1 is in everything.

1 Like

Thank you for also improving the performance for macOS, even if I know that many devs don’t like macOS.

Would you mind briefly testing the performance for me please so I could compare with my system? As an example the “i) Wet Bristles” with the size 250px, this gives me 4.2px/ms when krita displays the performance on the left canvas corner. I would really appreciate it, so I know more if the m1 would really be an improvement for me.
Does not have to be immediately, of course, just when you have time.

Note that these changes are for the canvas performance, not the brush engine performance – those are two different things. The brush engine on the M1 is hampered by the lack of support for ARM’s vectorization extensions. The brush/cursor speed is still 3.1/3.1 px/ms on the M1 for me. Painting feels completely fluid even with a complex color smudge brush like this one.

The really important number is the canvas FPS, because that’s what this improvement is about. It’s this for me:

Requested FPS: 71.0767
glSync effectiveness: 0.54491
Requested FPS: 80.9295
Requested FPS: 83.9568
glSync effectiveness: 0.530938
Requested FPS: 82.7869

In the stderr log.

1 Like

Okay i understand now the difference, this is what you said in the past if i remember correct, that the vectorization extensions for the arms called neon is not build in at the moment. Is this on the roadmap for future update or is it unlikly?

Thanks you very much for the testing. For me my fps are 120 while painting, with the “Debug logging of OpenGL framerate” option. It looks like my Radeon Pro 580X 8GB is not bad.

Yes – Dmitry and @IvanYossi are working on a special branch that uses the std::simd library instead of the older Vc library that does support the ARM vectorization extensions.

For me, after doing a lot of testing, I’m confident that we can now put Krita in the macOS app store, because it’s gone from annoying to really quite usable.

(Oh, and another thing I forgot to mention: the brush you’re testing with is a color smudge engine brush – and those cannot be multithreaded – other brushes will really benefit from all the M1’s cores. I’m still not an Apple fan, though, I’m a free software fanatic…)


Hey halla, one more small question for clarify.

You say that the smudge engine can’t be multithreaded. However, I read in a post from krita devs that you are trying to switch the engines to multicore with the help of CERN. Would this then also not apply to the smudge engine? Or only not for the M1 chip?
So really no chance that the smudge engine becomes more performant? Unfortunately I use almost exclusively the smudge engine.

Ah, that’s a different thing. All brush engines use a library called Vc with implements support for CPU vector instructions. This means that a for a given stretch of pixels, those pixels can be modified simultaneously. Multithreading is up a level, where we divide the image in chunks, and then work on those chunks simultaneously.


My macbook pro seems doesn’t support this(2015mid). :rofl:

OpenGL Info
  Vendor:  "Intel Inc." 
  Renderer:  "Intel Iris Pro OpenGL Engine" 
  Version:  "4.1 INTEL-16.5.2" 
  Shading language:  "4.10" 
  Requested format:  QSurfaceFormat(version 3.2, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CoreProfile) 
  Current format:    QSurfaceFormat(version 4.1, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CoreProfile) 
     Version: 4.1
     Supports deprecated functions false 
     is OpenGL ES: false 
  supportsBufferMapping: true 
  supportsBufferInvalidation: false 

Thanks for picking up the Krita weekly, never got time to restart that after I stopped, :sweat_smile: