@dkazakov I've been thinking about the options as well.

I've been thinking about this lately and I think we can implement this another way that wouldn't lower the performance. The problem with this implementation is that the pattern gets rotated for each dab placement. So there's two ways I can think of improving this, either apply the rotation and store it somewhere else outside of the paint operation or rotate it once at the beginning of the paint stroke and cache it somehow.

Insert layer above group layer only if active group layer is collapse, otherwise perform default action of inserting inside of the group layer even if the group layer is active. Closes #399103 - New layers made with group layer selected is created inside this

@scottpetrovic there's no point in working on changes if I don't present at least a bare minimum case for them :).

Yes, I agree, it breaks this workflow and I actually didn't think of the case where the group is empty. I think this should be an exception, a separate case so we have:

Remove ugly wall of text, simplify explanation, hope this is better.

I agree, the text is very lengthy and still more confusing than not. I'll rework it later with the critique in mind and I think best is something in the lines of what you mentioned @woltherav.

Maybe it's best if we make a diagram, what do you think?

@woltherav I find that original explanation very problematic, first of all it doesn't solve at all what it's trying to solve. Second it focuses only on size whereas PressureIn is generic, is not about the size setting. Honestly I tried to explain what PressureIn does without the analogy and it's even more confusing. But I'm willing to revise it if you have any other ideas, like I said, explaining it in terms of the original solution is pretty bad, it took me one full day to even understand PressureIn based on that explanation in the first place and it wasn't until I extensively played with the setting to understand what it actually does. And honestly I don't even think I can explain it in those terms, because I don't believe it myself. It doesn't do what the original author says it's supposed to do.

fixed some typos

I would like to help with the thumbs but honestly the conversation has been so disorganized I'm not sure it won't just be time wasted. How do we organize this better?! I understand there's little time before official release.

@Deevad no, I wasn't trying to push you to defend anything, I'm just trying to understand better what you mean, sorry.

@Deevad @woltherav ok, I can be sold on the fact that ink (specifically) can benefit variations in pressure curves, but the I would argue that the current ones [I haven't tried git-master, just the release 4.0.0-beta1 (git b322ae6)] offer very little variation making them almost indistinguishable from each other, the ones I pointed out, just play with them and see for yourself if you feel any significant difference.

Oh right, for manga, didn't think of that, alright, that's cool. I was thinking they look very good for bokeh effect if it weren't for that noise :).

@scottpetrovic here's my specific feedback regarding the default presets I don't see necessary and yes I agree this is very subjective:

So this is my proposal from my own pack for some of the things I think are missing in the default set, summed in this image:

@scottpetrovic sorry, wasn't my intention to be nebulous about the fx part of the set. The trouble I'm having with it is really with only 3 presets: the fx glow add and the fx value burn & fx value dodge as they are now. They are way too small (I think the size is 30) and the opacity is too low, it's very difficult to do anything with them, very hard to control and I personally think we can do a lot better and as far as this type of brushes go I'm leaning towards david revoy's set as I mentioned before. With the others from FX part of the pack only the thumbs need to be improved.

@rempt, @scottpetrovic in the current proposed krita v4 default presets I see 3 issues:

So then @scottpetrovic, is it a specific branch and how's the workflow on this? Should I just send PRs to a specific branch or give you brushes to check and you curate? or...

I don't think 6K is too big of a canvas, consider the fact that soon 4k monitors soon be standard. I think it's a good idea to start preparing for that and 2.5k images will be small on those, 6k will be medium size, not even that large. And even without 4k monitors, if you do work professionally (pictures that need to be printed, even 6k is medium in some cases), I think 6k is a reasonable starting point. So with this I agree with @ramonmiranda.

So I find the current FX Glow Add, FX Value Burn & FX Value Dodge (which isn't even value dodge, it's color dodge blending) pretty useless/low quality. I'd strongly lean towards the "FX" (multiply, dodge, color etc.) brushes that @Deevad has if he's ok with having them defaults in krita.

@rempt Yah I know that, but that's not friendly UI for the average guy and you need to know where the system images are store if you're in the case I mentioned, you just for example want to add that tilt symbol in the top right corner, plus you'd have to place it manually in the right place etc. Modifying manually by loading the preset in krita as image is not the way to go for this is what I think

Maybe I'm missing something, but there seems no way to modify a thumbnail once created, that is you have to create a new preset just to change the icon, say you forget to add one of those little info icons from the top left corner, you'd have to save a new preset just to make this change. Also undo would be nice on this interface if it's not too difficult to implement.

By the way, is this document: https://docs.google.com/spreadsheets/d/1wG82XO_NnMlsMSfccPjzgR2okBzU6ekr5RpZm5MvmVA/edit#gid=360332886 still being used in this task?

Can we really not have names like:

These are some of the modifications which reflect my own taste I'd make to some of the brushes. It's a really good start, I had to change very few things.

One more thing, I noticed the default precision is now 1 (lowest quality), in prior versions it's 5 (highest), I guess we should use 5?!

These are my thoughts on the new presets:

I've been thinking about it, been looking at some other software and here's my comments on the brush icons issue (grid view - so square icons specifically).

Yes, I agree about the separate task. Actually this is a point I already raised in the "brush stroke preview" task (don't know the exact name). I said that the graphic icon should disappear entirely and be replaced with the generated stroke (preview stroke) because it's a real pain to maintain brushes especially cause you have to generate preset icons over and over and over... it's more than annoying, it's a real limitation. I still think we should remove the brush icon and move on to generated preview only. :)

I'm all for more brush tips and textures with 1 condition. High quality. Many of the default ones in v3 need a lot of rework and they need to be fixed. I don't even understand how some of the 512x512 textures can be that bad, it seems like the native scaling (x1 scale) is low quality to begin with. So I'd definitely like less presets with higher quality brush tips/textures, 2-3 dozen sounds good to me and once you have a variety of nice brush tips you can easily make your own presets without searching for extra textures/images etc. I like this idea.

My beef with Krita v3 default presets is 2 things: redundancy and low quality. There are a lot of brush tips (especially foliage, flowers, leaves, etc.) that are extremely low quality. If you increase the brush size a bit they become pixelated and so they're useless with even medium-large resolutions (2-3K). Most patterns also suffer from this and that pattern scaling algorithm can be improved. If you take for example the dots pattern and scale it (no matter the value) it completely destroys the pattern, if it's anything other than scale 1 it's useless. So with all this in mind I made my own brush pack and I think it mostly follows the same category pattern you're talking about, I have them divided in A (digital), B (textured), C (traditional), D (environment - rocks, foliage, trees etc. - least used by myself), E (experimental - all sorts of cool presets), F (stamps). You can check out the pack here (completely free and opensource): https://goo.gl/Z8EofO and if you find anything useful let me know, we can change up the brush thumb to make it compatible for v4 and all that.

Don't know how this stuff is going, but if you're still working on it you might be interested in this to snatch ideas or maybe collaborate?! maybe.... just... maybe :D http://www.taron.de/forum/

I second @gdquest

@woltherav @scottpetrovic of course it can replace the icons entirely. What makes you think those inputs can't be simulated (tilt, rotation, clone, smudge, blending etc.)? Any type on input -> output could be simulated, that's why the program works in the first place.

I think this would be perfect for replacing the paintoppresset toolbar (F6 menu). Because this way it will remove the necessity for brush makers to create icons for the brushes.

In D6619#126994, @dkazakov wrote:

In D6619#125938, @jounip wrote:

Edit: I also just came across KisWrappedRandomAccessor. It would be preferable to use that rather than adding the new accessor function in the pasted code.

Yes, this accessor is used in the wraparound mode, so it can be reused.

About the speed being twice slower, it doesn't seem to be too bad. Probably, we could implement caching for the predefined angles using this algorithm link, and for all the other angles (which make the cache be, say, more than 2000 pixels in size) use this slow implementation.

@jounip, seems the paste you added is password protected.

Right, that's what I thought. And with that in mind... I have no idea how to speed this up... I'm open to any suggestions :)

So... it seems that all of the transformations are handled by OpenGL in QT. I'm guessing that's not the case in Krita? Fill operations are not performed using OpenGL are they? Browsing the fillRect code I couldn't find anything that would hint to this. So, in the end no matter where you put the rotation operation, you still need to do it for each dab which is going to be slow, even if it's going to be moved in the fill operation itself. There has to be a way to do this... :)

I saw your post on undo & new stuff. It looks very promising! I'm sure you're thinking about this, but I hope you're not going to stick with round blobs for the dab :P. So for the undo, I'm not sure if it's even possible, but I'd explore how things are handled in Corel Painter as that's the only other app out there(?!) that has watercolor simulation. I can't test it cause I only have linux, but I'd go and download a free trial version and I'd explore it a bit if I were you. I think what they do (which is something I read here - https://skipallenpaints.com/2015/04/04/working-with-a-very-wet-watercolor-variant-in-corel-painter-2015/#comment-35600, but I might have understood poorly). Is that they have a special layer for watercolor and the undo operation is for... the entire layer?! Which is just an erase operation now that I think about it.

I think I found where the fill is implemented in the qt source code: https://github.com/qt/qtbase/blob/e4c39d5e1e7ee8c2bba273e6d613ec519b7fa9c2/src/opengl/gl2paintengineex/qpaintengineex_opengl2.cpp#L745. It's... a lot of code there, don't even know if it's helpful to look at, I'll try to decipher it in the weekend...

@dkazakov, actually I tried checking the qt source code to see how transform is implemented in QBrush... still trying to understand, but yes, I think this is by far the best approach. My initial test was using QPainter & QBrush and that didn't have any performance problems on my pc... (but of course that didn't include any filtering strategies)

@dkazakov hi there! The problem is you can't really have "a big enough" fillRect(), unless you limit the rotation angles to some very specific ones for creating seamless wraparound. Or if we assume that a person doesn't do a mark of more than X pixels, but that's too many assumptions... With the method here you never loose seamlessness and you don't need a huge fillRect() for that.

@rempt, yeah but how? We need to use fillRect for each new position of the dab (offset) in the rotated mask space. I don't see how this can be cached...

Implemented @jounip's solution which works except it's too slow to be useful... there has to be a way to improve performance...

The code works, but the problem is performance, each time the dab leaves a mark on the canvas the rotation happens and it's super slow... if anyone can think of ways on how this can be sped up... this is the missing puzzle part.

@jounip, I don't understand how this can be. Here x & y are defined based on m_maskBounds such that (say for x as example), x falls within 0 & m_maskBounds.width() - 1 (disregarding offsets for now). Then in order to translate around center point you have to translate to -x - 1 - half_of_fillRect_width, rotate, then translate back to original position. But I don't understand how this rotation works, I tried playing around with the translation/rotation & as far as I can tell the rotation happens around the top left corner of the fillRect region regardless of the translation. So basically what I observed is that translation has no effect.

The other constructor rotates around X & Y, not Z as we need here. What does fillPainter.fillRect(x - 1, y - 1, rect.width() + 2, rect.height() + 2, m_mask, m_maskBounds); do? Does it fill a rectangular region with top left corner at (x - 1, y - 1)? I assumed that but it can't be right, because I try applying the inverse translation and it just doesn't match.

@woltherav well, I know why the offset happens, it's because the rotation is about (0, 0) in the fillDevice reference system, so an adjustment needs to be made in order to center the pattern correctly after rotation, but I am not entirely sure how this fillDevice behaves.

OK, so I was reading about QPainter, QBrush & such, there's the setRenderHint/s method which I'm using and I think it produces slightly better results. Although I don't think it can be improved much more with this set-up. As I understand it these hints might or might not be used but on QImage it's more likely they're used. With the KisPerspectiveTransformWorker I just don't know how to align the brush dabs. Maybe something will come to me later. Now one problem with this QPainter, QBrush approach is that I think the applied value (here grayValue) is not the same as *iter->oldRawData() so I'd appreciate some help with this one.

In D6619#124101, @woltherav wrote:

That is really bizar it is so slow. Did you try the usual speed-up thins, like maybe caching the transform somehow(by making a member variable) and only recreating it when the angle changes? That could make a huge difference.

After thinking about it a bit I think that the best way would be to make a createLineIteratorNG & a KisWrappedLineIterator in the same idea as createHLineIteratorNG, but that can iterate taking in account a rotation & filter strategy. The filter might be too much, maybe bilinear is enough for this operation so just hard code it.

OK, before anyone says anything... I finally understood how to use KisPerspectiveTransformWorker & KisTransformWorker to rotate the fillDevice... I tried both of them and the rotation quality is waaay better, but there is no way we can use this, it's extremely slow. I've only played with it, the offsets are wrong, but I managed to correctly rotate the pattern in a somewhat seamless way (except for this offset problem). But as I've said... it is unbelievably slow, unusable. The QPainter + QBrush solution I submitted is way faster it seems... it's only the quality of the rotation is awful...