From the video, my guess is that you try to turn off instant preview. There's not really a lag so much as a delay between the start of a stroke and the actual rendering, which in other cases I've seen this was caused by instant preview.

Thanks for your patience.

If I disable "Instant Preview" this is what I get.

https://vimeo.com/231858731

Any Ideas? I have a very clean Windows 10, I have about 20 programs, and Windows is very optimized for performance. I don't have Cortanas and that kind of ****.

Better in Linux?

I am not sure. When boudewijn repeated the setup on his windows machine I saw the same thing. I cannot try to start to reproduce this on my own laptop because the system can't handle even a grayscale 8bit image at that size. so it might be a bit smoother on Linux, but sadly the way instant preview works has been our best bet to solve this problem. The delay at the start is probably something to look into, but it'll depend on how busy we are when we can look into it. Last weeks have been very busy.

Hm, this is really weird. On my pc this kind of brush works much faster (I tested 10k canvas though). Without Instant Preview it works like on your video with IP, with IP it works in real time with no lag.
Pretty old win10, i7 6700 and quite old gpu, bunch of programs in background.

Upd: tried 12k canvas and brush with 5 precision, it's noticeable slower but still better than your video.

Can it be problem of the brush itself?, even with Artrage I can work in 8.000 x 8.000 without noticeable lag.

I think it's something in my configuration.

TheraHedwig, I am very grateful for your work, you work very hard. I understand there are a lot of things to do. I can wait, I have Krita installed and periodically I check for updates and do some tests.

When this works fine I will change to a Linux/Krita configuration.

Thanks a lot

I am doing some test with all posibilities, and I think the problem is only the brush size. Even in a 12000 canvas when the size is about 300/400 px works fluid, but when the brush size is increased it progresively goes slow and more slow. This is not only a Krita issue, it happens too in photoshop, but more slightly.

Definitely it's not a problem of the canvas size. I have created a 3000x3000 canvas and the lag is still there.

It's a matter of the brush size.

I have a questions to boudewijn.

Background
I am using krita on my mac.
I have created 600dpi file which size is 126MB, opening krita it states that the image size is 4.4 GB (it is strange that RAM that is needed is so huge and does not correlate in actual size).

You say in your post that:

But if you zoom so all of the pixels are visible, and try to paint a big diagonal stripe over the image on, say, the second layer from the bottom, then Krita will have to access nearly all of the contents of all the layers to create the final rendered image. That means that everything has to be loaded from the swap into memory, from memory into the cache, and then swapped out again.

My questions are:
When I am working in specific area so all of the pixels are visible then do i really need to have all the layers information also the once that are hidden?
What if I do not want to use all the layers in the file in my finale image example https://www.youtube.com/watch?v=gug7ppwjlTo&t=349s
(Also a bit strange that when i use "save as" the original file name stays visible in saved document just strange - my first idea was that would there be any connection between those files and that is why the memory is so huge)?

Sorry if stupid questions or not suitable in here.
I am completely new in krita?

tomwh wrote:I have a questions to boudewijn.
I am using krita on my mac.
I have created 600dpi file which size is 126MB, opening krita it states that the image size is 4.4 GB (it is strange that RAM that is needed is so huge and does not correlate in actual size).

No, that is not strange. First, you need to stop thinking in terms of dpi. You can have a 600 dpi image with a width of one inch by one inch, which would translate to 600 pixels by 600 pixels. That's not big. It's the pixel count that counts. Then Krita files on disk are compressed. They need to be uncompressed when loading into memory, and depending on the image contents, compression might make an image very small: a regular raster of black and white pixels, for instance compresses really well.

Then you need to consider how an image is rendered: you have the actual layer data. The layers are rendered on something called a "projection". This projection is as big as your image in pixels, and has the same channel depth and color model.

In order to render larger image, we use mip-mapping: we have multiple versions of every layer and the projection, at 100%, 50%, 25% etc. That takes memroy.

Then we need to render the projection to something that can be shown on screen: depending on whether you have canvas acceleration enabled, that means that we need width * height * 4 bytes of GPU memory or CPU memory to store the screen image.

tomwh wrote:You say in your post that:

But if you zoom so all of the pixels are visible, and try to paint a big diagonal stripe over the image on, say, the second layer from the bottom, then Krita will have to access nearly all of the contents of all the layers to create the final rendered image. That means that everything has to be loaded from the swap into memory, from memory into the cache, and then swapped out again.

My questions are:
When I am working in specific area so all of the pixels are visible then do i really need to have all the layers information also the once that are hidden?
What if I do not want to use all the layers in the file in my finale image example https://www.youtube.com/watch?v=gug7ppwjlTo&t=349s
(Also a bit strange that when i use "save as" the original file name stays visible in saved document just strange - my first idea was that would there be any connection between those files and that is why the memory is so huge)?

Sorry if stupid questions or not suitable in here.
I am completely new in krita?

No, if you're only working on part of the image, unless you have something in your layer stack that needs the entire image, like some filter layers, or a layer style, only the bits that you touch will be updated. Hidden layers are not taken into account when recalculating the projection, but they are still loaded, so still count towards the memory needs of the image.

I have two files lets say file1 and file2.
File1
Image size 2.1G
Fail size 228MG

File2
Image size 4.4G
File size 89.6MB

File2 has swap usage issues while File1 that contains more different layers and content has no issues at all.
What might be the reason and why I have issues with file that has smaller file size (I am using Krita v3.2.0 in one computer and other v3.3.0)?
What are best practices when I want to use some content of krita file in another project? (I just copies the file, deleted what i did not want. Was it right what I did - I am suspecting that this might be the reason?)

Like I tried to explain, since Krita files are compressed, the actual file sizes are _not relevant_. They do not predict anything useful about the file size once opened. If after loading Krita tells you it takes more memory, it takes more memory. This is not something weird, and without access to your files (which I don't want; I don't have time to investigate and tell you exactly what's up with one file or another) I cannot tell you why one file would take more memory than another. https://docs.krita.org/KritaFAQ#How_muc ... ge_take.3F has a simple formula for calculating memory usage; there are some quibbles, but with that formula you should be able to do the sums yourself.

Thanks for your reply and explanations.