Bug 381362

Summary:	Long Rerendering upon creation and moving of a layer above the rest of the layers in a huge file
Product:	[Applications] krita	Reporter:	reptillia39
Component:	Layer Stack	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	halla
Priority:	NOR
Version First Reported In:	4.0 pre-alpha
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description reptillia39 2017-06-18 13:50:34 UTC

How to replicate: Make an .KRA file with over 300 layers with several layer types and mask types, and over a resolution of 2500^2, and with many group folders. Try to add a layer on a upmost group layer which has several different group layers under it. Move the layer.

I would like to be able to send the file here, but there's a file size limit. The file I have is approximately 240K KB or 234 MB. I guess I can send it to e-mail.  

Additional Information: 
The version of Windows used is Windows 10 x64 - Creator Update

Additional Comment: There has been a huge operating speed increase of Krita as of 4.0 Pre-Alpha, and there's still issues, but it's getting there. 

Workaround - 
1) Lock as many layers and if it under a group layer, collapse the group layer, and then add layer.

Comment 1 Halla Rempt 2017-06-18 14:06:39 UTC

Hi,

Can you share the file through a google drive or dropbox or wetransfer link? In any case, I'd like to run this with a profiler to see whether there's something more to optimize, but in general, I fear you're running working close to the limits of what Krita can handle.

Comment 2 reptillia39 2017-06-18 14:16:03 UTC

https://1drv.ms/u/s!Amfdr1iy4x7TgRsaqHq7hKCBA3k1

Download link to file generated by OneDrive

Comment 3 Halla Rempt 2017-06-18 16:33:40 UTC

Um... Why is this file 16 bit float/channel? Are you doing HDR stuff with it? That doubles the memory needed compared to 8 bit rgba, and is an all cases slower than 16 bits/channel rgba. The file takes about 10gb of memory, so I'm not surprised that Krita is struggling a bit...

Comment 4 reptillia39 2017-06-18 16:43:33 UTC

From what I have experienced, I sort of find 16-bit float faster than 8-bit integer for large canvases, but that could be just me which is why I set up 16-bit float to be the default on my end. I also find 16-bit float faster than integer as well just from typical usage. Maybe I should run 4 tests just to make sure. 

Besides a little quirk here, and there, Krita doesn't seem to struggle that much from my end, but I can never get it to load in my laptop. Loads fine with a very expensive desktop.

Comment 5 Halla Rempt 2017-06-18 17:51:26 UTC

Ah, if 16f is faster, that probably means you're using an nvidia card? It still takes twice as much memory, and if your laptop doesn't have 32 gb of memory, a 10mb image is a bit much -- krita by default only uses 50% of the memory in the system.

Comment 6 reptillia39 2017-06-18 18:09:02 UTC

You got me, I am using a NVIDIA card. Yes, it is a little too much for average computers. Any way, is there any possibility of optimization?

Comment 7 Halla Rempt 2017-06-19 08:41:20 UTC

We're always looking for optimizations... But with 10gb of image data, we're basically running into bus bandwidth problems -- it's getting hard to get all pixels to the CPU for calculations. I'm keeping your file, though, and will be running some performance tools to see if there's anything obvious.

Comment 8 Halla Rempt 2017-06-19 12:46:44 UTC

I've run a long valgrind job, and the interesting bit is that Krita seems to spend about 60% of the time updating the filter layers.

Comment 9 reptillia39 2017-06-20 15:28:17 UTC

I believe the blur filter is what taking the most amount of time. I had to disable blur filter on the old 3.1.4.

Comment 10 Halla Rempt 2017-11-26 13:40:15 UTC

Another valgrind run doesn't show anything particular that we could optimize; with a file like this, you must expect performance to suffer.

Comment 11 Halla Rempt 2017-11-27 09:00:44 UTC

*** Bug 382106 has been marked as a duplicate of this bug. ***