Bug 73781

Your observations are absolutely correct tablet events get somehow stored up, and mouse events are skipped whenever the application is too slow to handle the events in event loop.

There are two problems here -- the first is that Krita only computes the masks
when the brush is selected, and it computes a mask for every pressure point. Computing these masks at startup time makes Krita use lots of memory, computing the masks whenever a brush is selected makes Krita too slow. Obviously, I should find a clever way of making the mask computing faster, but I cannot think of one at the moment.

The second problem is compound problem, one which I have a hard time of solving. The first problem is that Krita -- after retrieving the brush mask, which may have to be computed, see para above -- first draws the brush mask in the selected colour on a temporary layer. I suspect I am not doing this in the most optimized way, and, worse, previously I could reuse the temporary layer for every position on the line, but with the advent of pressure sensitivy, caching the temporary layers began to be hard on memory, so I decided to skip the caching. And then, the temporary layer is blitted onto the target layer -- again a lot of loops, and again, I am sure that this could be optimized. Finally, the result is shown on screen. For that, Krita loops through all layers, and composits the changed rectangle onto one temporary layer which is converted into a QImage, which becomes a QPixmap, which is shown on screen.
This happens when I call notify() -- and again, this is a slow process which I should optimize.

Looking at other open source painting applications (there aren't all that many, a few Gimp clones for BeOS and OS X that haven't implemented drawing yet, and a few (Perico, XPaint) that haven't implemented drawing with brushes, I have to conclude that the Gimp reaches its impressive responsiveness through a combination of trickery, hackery, special-casing, optimized assembly and a lot work by people who really knew what they were doing. Worth trying will be drawing directly onto a temporary layer that's as big as the viewport (or image), and only blitting to the target layer when the mouse is released or pen pressure becomes 0; that would drawing more responsive, I think, once the masks have been computed. I might also try to skip the mask computing, and try drawing directly from the mask's QImage. And I am sure that there are many smaller and bigger optimizations to be made everywhere. But I really need more than small optimizations; plans for more complex drawing tools make it necessary to have as many millsecs available from computing things between mouse events as possible, which means that updating the screen must be really fast.

Anyway -- thanks for trying Krita -- I am working on both issues, but, not being the slightest bit knowledgeable, I cannot promise quick improvements. If anyone has an idea...

Thanks to Adrian Page and Roger Larsson this is much better now, but the caching of pipe brushes still leaves a lot to be desired.

Only the first stroke is a problem for me now.
But that might more be related to computer upgrade AMD 2800+ :-)

No, it has little to do with your new computer -- although that's nice to have, of course. Drawing strokes once the brush shapes are loaded into memory is pretty smooth now, thanks to Andrew Page's work. You can even switch between interval-based and immediate update to test the difference.

The problem now is the generating of the brush shapes in the necessary sizes. This takes far too long, especially for image pipe type brushes, but I hope we'll be able to speed it up soon.

I have some code in progress that can scale brushes to any size, from any size. This will allow us to greatly reduce the number of pre-generated brush sizes, which means we can hopefully generate them on loading the brush rather than on first use. That should fix this problem and also reduce memory consumption. Another benefit is that we can generate brushes of non-integral dimensions which will mean brush strokes with a tablet will become smoother.

On Sunday 25 July 2004 15:16, Adrian Page wrote:
> ------- Additional Comments From adrian pagenet plus com  2004-07-25 15:16
> ------- I have some code in progress that can scale brushes to any size,
> from any size. This will allow us to greatly reduce the number of
> pre-generated brush sizes, which means we can hopefully generate them on
> loading the brush rather than on first use. That should fix this problem
> and also reduce memory consumption. Another benefit is that we can generate
> brushes of non-integral dimensions which will mean brush strokes with a
> tablet will become smoother.

Wonderful -- when that's done we can likely close this bug, and the other bug 
I assigned to you today. Sounds like great stuff.

Judging from experiences with the current state of Krita CVS, this problem is solved.