After one week of no answer, I tried to implement the shift+wheel vertical positioning. It's not useful because of the nature of the timeline and how it's showing and hiding the layers. I think it's better not to add it. The original version seems working fine, so I'm not waiting for the revision and committed it to master.

I just have an idea for some improvement, but not checked if it's possible:
this is horizontal movement now, maybe shift+wheel could be the vertical, if more than one layer is visible. Ctrl+wheel is nicely working to select a range of frames (at least on Linux).

Thank you @dkazakov, pushed commit 4f3d21273b4b7e984af447696076ab23dc4669e2.

also found some QLabels without translations, please check:

After a quick search, there are still some setToolTip() calls without i18n():

Pushed to master.

This is the final version then.

In this version I added a universal clear function to KisToolUtils. This is a better place than KisLayerUtils because the other contents of KisLayerUtils are maintaining a lower level of functionality, below the UI. This new function can clear the canvas with or without its selection. I also modified the deleteSelection() function in KisTool to use this new function.

As far as I can understand, the original solution closes and reopens the threads. This works, just takes too much time and resources. So a solution to wait for a monent when there is no thread running, is good. It's only a hazard for the future, currently nothing creates new jobs infinitely during the wait.

@dkazakov : How to make it? As I see I cannot put KisPart, KisView... etc. includes nicely into kis_layer_utils. The files in libs/image cannot include things from libs/ui. What if I create the new function in KisTool instead?

I've added the new tool function deleteAll(). It clears the contents regardless of the selection. Perhaps it will be useful somewhere else too. Currently implemented as an empty function for most of the tools.

Ok, so I removed the KisPart modifications. It's not worth the effort, there are just too few occurrences in the code. This solution is working, the only bad thing is the masking with the selection.

Just a minor change: I call the deleteSelection() function directly now.

Unfortunately KisImage is below KisView in the hierarchy. So it's easier to add this function to KisPart instead. I've checked the code and it would be useful a similar function for KisDocument too.

Ugh, I don't really understand the concept of this node manipulation interface yet... But what about to add a member function for the image itself?

@rempt: from the first menu, only the "&File" and "&Save" keys has no msgctxt in the .po file. And on your picture these are the only translated ones.
Good night!

About the ampersand: I think the translation is using a hash table for the i18n translation. Maybe the hash code calculation drops the ampersand (perhaps together with other "whitespace" characters) for some reason. In this case the two strings has the same hash id.

This is the next version. Is there a better way to get the viewManager address here?
If there is a selection, this solution clears only the parts inside it.

I understand your opinion and I agree, but there are two things here:

The cpunters for the threads is a good idea. For me this solution is good if the number of the threads and their order cannot change during the wait cycle.

I think it's good now, no crash anymore.

My problem is still happens, perhaps not related but who knows? This is what I found:

I have a canvas and OpenGL on. Then I switch off OpenGL and exit the program. The program crashes with segfault in KisOpenGLImageTextures::destroyImageTextureTiles(). The crash happens when it calls delete tile, the deleted tile is the first on the list and it's value is not NULL.

Updated the .csv page. I also included a picture from the TVPaint GUI for the export settings, I hope it won't hurt them, but please check it.

@voltherav: I've created the page, please check and feel free to correct it. I'm thinking about some picture illustrations now. What do you think, could I add screenshots from TVPaint as well?

Ok, I'm going to make something for the csv format. But I need somebody to check the grammar, my English is a bit weak.

@dkazakov, your idea worked perfectly! It solved the crash problem too. I also added the cleanup part, please check it.

Never mind, the leak still happened without this, so I commit and close it.

@rempt I still have the original code here. Is there already a different solution for this?

If you look closely the difference between these that when the cache exists and there is no frame to view (cache miss), the original version does nothing, but the new one goes to the joined else case and view the frame without the cache. If the frame is not in the cache, it only starts to render if no another rendering in progress. The problem was that when the frame is not ready the program never shows it (even if it's ready later), so you see the last viewed frame. It's really annoying when you scrub on the timeline frame by frame with the mouse.

I've found nothing. it seems the original version works perfectly. so now I abandon this revision, I hope these still remain here for the archive.

So I figured out what is the problem here. The animation interface is part of the private structure of KisImage. But when destroying the image, first its root layer destroyed, and only after that comes the private structure with the animation interface. But if the animation interface has a work in progress, it's possibly wants to use the root layer after it removed. It seems the animation interface is not what waitForDone() waiting for. I decided to create the animation interface after the rootlayer created, and to delete it before the rootlayer deleted. I think this is the clear solution.

I see now when this happens easily. If you modify the animation, after some idle time the program starts building the cache. If you close the document during this, it has a high probability to crash.

Update: It's strange but sometimes only the root pointer is null... I really hope this is not about threading again...

The cache is not color managed probably to increase the rendering speed. The playback in CMYK space is pure garbage, I think because of the extra colour channel. But CMYK has no meaning in the film industry. XYZ space can be important for cinema quality animations (DCP) . What is the best solution then, to add a color space conversion ?

A possible solution I think, to use the cache only if the color space matches enough (ie. it's well usable in all RGB spaces with minor color distortions) and to use the cacheless redrawing otherwise.

Update: I figured out that the loop is a possible deadlock, because the OpenGL cache rejects the new rendering if there is already a rendering in progress. So I reverted this back to its first version, only removed the warning message handling because there is no message at all.

@rempt already reverted these commits and I made a differential with a modified version: D1195

Thanks, I'm making a different solution now.

The problem here is the destructor of the TileData which locks the mutex. It happens when the last QSharedPointer reference to the tile destroyed, sometimes it happens between KisTileDataStore::beginIteration() and endIteration() which also locks it. I agree it's bad so I have to use the KisTileDataSP type for the KisTileDataList to avoid this.

@dkazakov: the commit was related to the multi-thread access of the tiles. The behaviour of the Composite Copy bug looks similar to this bug, but of course there can be another reason. Sorry if it's not related, I move it to a different topic then.

Committed my solution into master.

So my opinion is this: the KisTileData::ref() and deref() functions are not thread safe. I made a test and it seems these are actually callled from the tile creator thread and from other threads too (probably that's why the atomic ref() used here). A worst case scenario could be like this:

I updated the code to the signal handling version. I can't decide which one is better. This takes half computing time but it is a deadlock if somehow the frame not appearing into the cache.

I don't know but I see some problems in the kis_tile_... part too. Maybe not related to this bug and maybe it causes problems only once in a decade, but still.

I'm trying to solve this. My suspect the is the atomic int ref() - deref(), it is not safe enough (see the KisTileData::deref() function as an example), since it is theoretically possible for a different thread to ref() a tile between the deref() function and the actual erasing (freeTileData()). But this is very unlikely, so perhaps there are other problems too.

Just an idea: perhaps it's not a big problem, but this is a cpu hungry solution. You could wait for the threads one by one, always for a single thread to finish. Then you can do it with something like pthread_join() or QThread::wait(), I don't know how the threads are implemented.

Not really a hangup but I get segfault very often when closing Krita (perhaps malloc corruption). It's just not really noticable, only a final message on the terminal. Also often it says there are remaining tiles in the memory, whatever it means.

I'm trying to reproduce this bug, yet without success.
But I got this message once while animating:

I have a problem with Krita now... after pulled your commit c17ed27409710a87cea1e7f74015873967095baf, it seems the program uses 100% CPU even in idle after startup, without any documents. As I see it refreshes the KisShadeSelectorLine widget again and again without any reason.

Pushed to git.

Thank you :)

I made some more tests. GNU c++ knows the difference between (a < b) and (!(a >= b)) so I added an extra modification in the limitValue() to filter out any remaining NaNs. Interesting that this modification alone solves the original problem. But since I'm not sure what happens in other compilers, it's safer to keep the original alphaValue test solution too, just I changed it to the epsilon version.

Added the missing error messages and pushed it to master. This was my first git push to Krita by myself, so I hope it landed correctly.

First I used the (alphaValue > 0) version but then I was curious what happens here. But the epsilon version is better. We could add extra safety with tricky comparisons as well (and maybe it's worth to search for other occurences in the code):